This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: That's Codd roe, of course...
Feed Title: Avi Bryant
Feed URL: http://smallthought.com/avi/?feed=rss2
Feed Description: HREF Considered Harmful
...how about we give up [object-relational mapping] and instead try lacing relational semantics into our favorite language of choice?
I'm less skeptical than James is. O/R mapping adds a huge amount of complexity to a project, and with dubious benefits: when you're not tracking down bugs in the mapping framework or obsessing about performance, you're chopping toes off your object model so you can shoehorn it into a relational schema. I've seen projects nearly fail because too many resources were thrown away trying to "solve the O/R problem" - which always means, solve it in this one very particular context, since there are so many inherent tradeoffs that any one framework is rarely optimal for two different scenarios.
I came out of one such project determined to try something different. Inspired somewhat by SchemeQL, I built a library that models the relational algebra in Squeak. The Relational Object Expressions library, or ROE, doesn't do any mapping, but it does put the world of tables and rows on an equal footing with objects. Relational expressions (ie, queries) are first class objects, which can be easily passed around, composed, and introsopected. They respond to the Collection protocol, which means that from the outside they look and feel like an ordered collection of Tuple objects, but they're lazy - composing them and filtering them is free, it's only once you start iterating over the data that a single SQL query is built and sent out to the database.
Let me give you an example of what this looks like. Say you had a model with a Course table and a Professor table, where Course had a "professorID" foreign key, and you were trying to find the titles of the first 10 courses taught by a professor with a certain name. You would have objects ("concrete" relations) representing each of those tables, called, say, "courses" and "professors". Iterating over the first of these (courses do: [:ea | ...]) would be equivalent to (and would in fact generate) "SELECT * FROM Course", and would give you a Tuple object for each row in the Course table. We need to build a more complex query:
courseTitlesForProfessorNamed: aString
|courses|
courses := (professors * courses
select: [[:ea | (ea lastName = aString) & (ea id = ea professorID)].
^ (courses project: #title) copyFrom: 1 to: 10.
First join "professors" and "courses" to produce the cartesian product of the two tables - this is like a collection of Tuple objects containing the columns from both tables, in every possible combination; pretty standard relational algebra stuff. Then we do a #select: on that table to narrow down to the rows that meet two criteria: first, the "lastName" column has to be the one we're looking for, and second, the "professorID" foreign key from Course has to match the "id" column from Professor. Then we use #project: (another standard relational operation) to cut down the tuples to have only the "title" column, and #copyFrom:to: to grab only the first 10, and return that as the result.
But this entire method would happen instantly, with no calls out to the database. Only once someone took the result and tried to actually iterate over it would the entire SQL query, looking something like
SELECT title FROM Professor, Course WHERE Professor.lastName = 'Foo' AND Professor.id = Course.professorID LIMIT 10
actually get generated and sent. If someone wanted to do some further filtering (say, look for titles beginning with 'A') first, then that further criteria would get lumped into the same query.
Now, I know a group that have deployed a large Seaside app for an insurance company using Roe pretty much straight as it's described here, as a much better interface to a relational database. But I actually think that the true benefits will be from leveraging the extra information provided by these relational expressions to build a new kind of O/R mapping. The extra information is key. If you had that "SELECT title ..." query as an SQL string in your program, it's completely opaque - the framework can present the results to you as bare rows, and that's it. But with Roe, the framework knows exactly what those rows *mean* - for example, it knows they will have exactly one column, and that it came from the "title" column of the Course table. It would know this no matter how many joins, self joins, aliases, selects, etc, had gone into making up the query. So it could, say, present the results as a collection of partial Course objects, with the #title filled in and placeholders or cached values or who knows what in place of the rest of the data. I think combining optimized, relational queries with traditional metadata-heavy O/R mapping (minus the caching, maybe more on that later) could be quite powerful.
Previous Topic
