The complaint was that there aren't any mature libraries that go a step further, beyond feeding manually-constructed query strings to the DB connection, preventing injection vulns at the type level, etc. In an OO language this would be an object-relational mapper. I think the functional crowd is still trying to figure out what a "functional-relational mapper" is supposed to look like.
It's not that SQL queries are difficult to compose, it's that ORMs enable different abstractions to emerge, at least when used appropriately; I'll admit though that junior developers are drawn most to ORMs because they limit exposure to SQL. I'd recommend you check out a legitimate ORM that implements the Data Mapper family of design patterns such as SQLAlchemy or Hibernate.
(Incidentally, DataMapper in Ruby doesn't in fact implement the Data Mapper pattern, which I find irritating.)
I think ORMs do a fine job, excellent even. The problem is that you may be using O's which require a lot of M'ing to from the R's ;)
So if you don't do mainstream OO, then you probably don't ever need ORM. SQL databases are powerful relational engines in their own right - many ORMs have to replicate a lot of that functionality into their memory based stuff (which can be good, but its more work).
I guess its all slowly fading, as I am led to believe the trend is away from relational data to distributed data, which has a different set of problems...
I'm using Haskell + CouchDB. The bindings are simple enough that I've been able to hack fixes for them pretty easily, and just as importantly, Haskell's GADTs are much easier to translate into JSON than they are into SQL rows (at least I thought so). Turning around, you can spit JSON back up at the web layer after some mapping, filtering and processing, so it's not as if you'd wasted effort by writing JSON instances for your data.
11 comments
[ 4.6 ms ] story [ 42.7 ms ] threadHaskell is not ready yet...
The complaint was that there aren't any mature libraries that go a step further, beyond feeding manually-constructed query strings to the DB connection, preventing injection vulns at the type level, etc. In an OO language this would be an object-relational mapper. I think the functional crowd is still trying to figure out what a "functional-relational mapper" is supposed to look like.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/h...
http://www.maubi.net/~waterson/hacks/hdbc-mysql.html
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/h...
Nop, not ready yet...
Seriously, how hard is it to compose a SQL query?
On that topic, anyone know of a decent mysql lib for ruby that just lets me query and iterate over the results?
The one constantly at the top of google results is at tmtm.org, but my understanding is that it's not threadsafe or particularly speedy.
I saw something called asymy made by tptacek, but my impression was that the project was abandoned... Thomas, any comment on where that stands?
I'm also a fan of Sequel (though I wish it had a different name).
(Incidentally, DataMapper in Ruby doesn't in fact implement the Data Mapper pattern, which I find irritating.)
So if you don't do mainstream OO, then you probably don't ever need ORM. SQL databases are powerful relational engines in their own right - many ORMs have to replicate a lot of that functionality into their memory based stuff (which can be good, but its more work).
I guess its all slowly fading, as I am led to believe the trend is away from relational data to distributed data, which has a different set of problems...