Conflagration over ORM's...
The best part about reading blogs and such is that fun little tempests in a teacups come along and you get to play along at home by post to your LJ that no one reads.
So now we've got ORM's are a Thing of the Past(and of course hacker news has a thread), and a fun "rebuttal" from Debasish Ghosh: Are ORMs really a thing of the past?
Of course, all this is really just a pretext to pimp my Anti-ORM. Although I haven't updated it much since its release, it takes a different approach. I've not really had a good argument about what's wrong with my approach either. Instead of "generating" a domain model or some such, my SQLC Anti-ORM just makes it easier to write SQL and put that SQL in a class in a method, as a prepared statement. And it provides an extremely simple mechanism(straightfoward Java beans) of wrapping result sets in Iterators of "structs"(you don't have to use it, of course, so it doesn't get in the way).
This has a nice predictability bonus too, actually, since it never caches, and never tries to be smart about connection pooling(it assumes you give it a connection, and the iterators are Closeable instances and automatically call close on the ResultSet when you iterate to the end). Now, apparently this is probably the "wrong" solution according to some, but I have no troubles writing SQL, and in fact, it gets that PreparedStatement "syntactic garbage" out of the way and solves the "Counting ?'s problem"(setX(n, value)).
Of course, I think .Net's LINQ is a _more_ interesting way to do it. But I think the people I know using LINQ would agree that its as much a "different path" to the ORM/no ORM debate as my approach.
As it stands, I would like to make my approach look more like LINQ, but the big "next steps" I want to take with it involve adding a "GUI tester" that lets you interactively try the queries, and schema-based static type checking: You pass a SQL schema to the compiler and it checks that your queries are compatible with that Schema. My other big tweak is to add a "module" pattern to my schema's and query models so that I can have modular schema's and essentially have a simply-typed-lambda calculus like module layer compile down to "flat" SQL(yes, this is another way of saying "Steal ML's module system and apply it to SQL/relational query languages").
Of course, many of the "ORM problems" people mention like requesting all records to do a simple aggregate(that an indexed SQL DB could do in an insignificant amount of time...) are still problems with my approach. But I firmly believe that "targeting the low hanging idiots" argument is fundamentally flawed. Idiots will screw up anything. And some of those "idiots" just need some help that they aren't getting. And some of those "idiots" see impenetrable walls of too-much-confusing-jargon + RTFM attitudes and somewhat correctly write off your "better way".
Anyway, if anyone out there is interested in using my "Anti-ORM" I would love to hear about it... :)
So now we've got ORM's are a Thing of the Past(and of course hacker news has a thread), and a fun "rebuttal" from Debasish Ghosh: Are ORMs really a thing of the past?
Of course, all this is really just a pretext to pimp my Anti-ORM. Although I haven't updated it much since its release, it takes a different approach. I've not really had a good argument about what's wrong with my approach either. Instead of "generating" a domain model or some such, my SQLC Anti-ORM just makes it easier to write SQL and put that SQL in a class in a method, as a prepared statement. And it provides an extremely simple mechanism(straightfoward Java beans) of wrapping result sets in Iterators of "structs"(you don't have to use it, of course, so it doesn't get in the way).
This has a nice predictability bonus too, actually, since it never caches, and never tries to be smart about connection pooling(it assumes you give it a connection, and the iterators are Closeable instances and automatically call close on the ResultSet when you iterate to the end). Now, apparently this is probably the "wrong" solution according to some, but I have no troubles writing SQL, and in fact, it gets that PreparedStatement "syntactic garbage" out of the way and solves the "Counting ?'s problem"(setX(n, value)).
Of course, I think .Net's LINQ is a _more_ interesting way to do it. But I think the people I know using LINQ would agree that its as much a "different path" to the ORM/no ORM debate as my approach.
As it stands, I would like to make my approach look more like LINQ, but the big "next steps" I want to take with it involve adding a "GUI tester" that lets you interactively try the queries, and schema-based static type checking: You pass a SQL schema to the compiler and it checks that your queries are compatible with that Schema. My other big tweak is to add a "module" pattern to my schema's and query models so that I can have modular schema's and essentially have a simply-typed-lambda calculus like module layer compile down to "flat" SQL(yes, this is another way of saying "Steal ML's module system and apply it to SQL/relational query languages").
Of course, many of the "ORM problems" people mention like requesting all records to do a simple aggregate(that an indexed SQL DB could do in an insignificant amount of time...) are still problems with my approach. But I firmly believe that "targeting the low hanging idiots" argument is fundamentally flawed. Idiots will screw up anything. And some of those "idiots" just need some help that they aren't getting. And some of those "idiots" see impenetrable walls of too-much-confusing-jargon + RTFM attitudes and somewhat correctly write off your "better way".
Anyway, if anyone out there is interested in using my "Anti-ORM" I would love to hear about it... :)