[Seaside] database and eomodel

[Avi Bryant]

On Sun, 13 Apr 2003, Alain Fischer wrote:

> Hi Todd,
>
> Thanks for your EOModel library. I will try first with Tantalus since
> it is near EOF, this what I am using. But Glorp seem interesting also.
> Selection in glorp seem more powerfull and mor smalltalky than
> selection in Tantalus

It's not that selection in Tantalus (that is, building non-trivial
queries) is non-smalltalky; it's that it's largely non-existant ;).
Compared to nothing, Glorp's selection is definitely far more powerful
(and, indeed, Alan has done some very nice work in this area).

Ultimately, though, I'm not convinced that the TopLink-style select blocks
are the right way to go.  They're very fragile, in that they're only
mimicking Smalltalk semantics, and in a very limited way; it's hard
sometimes to know what you can get away with and what you can't (for
example, usually "select: [:ea | ea = 'foo']" will work but "select: [:ea
| 'foo' = ea]" will not).

But the main concern that I have with them (and with traditional O/R
mapping in general) is that they're eager - the instant you do a select,
all of the data gets pulled in, even if you're going to throw away most of
it in a further pass of filtering.  What I'm trying for with Roe is a way
of properly modelling the actual semantics of the query (at the relational
level, not the object graph level), so that queries can be composed and
manipulated as first class objects, and the database is only ever hit at
the last possible moment.

For example, let's say I have a table "instructor" with a to-many
relationship to another table "course".  I might have a #courses method on
an Instructor class that returns a collection of these courses, and I
might be trying to find out if a particular course is among them:

anInstructor courses includes: aCourse

(ignore for the moment that it might be better to do "aCourse instructor =
anInstructor").

The usual O/R approach would be to first fault in all of the Course
objects in courses, and then send #includes: to the result.  So, you get
a query something like

"SELECT * FROM courses WHERE instructor_id = foo"

followed by a linear search on the Smalltalk side for the right course.

With a proper lazy querying implementation, the send of #courses builds
the above query but does not execute it.  Sending #includes: just adds
another clause to the query, so that you now have the equivalent of, say

"SELECT * FROM courses WHERE instructor_id = foo AND course_id = bar"

This is what actually gets sent to the database, and the number of rows in
the result will tell you whether the #includes: should return true or
false.

Now, this particular special case could be added to, say, GLORP or
Tantalus (or could be hand-optimized by inverting the question), but what
I'm interested in is the general approach; my hope is that Roe's model of
an SQL-equivalent relational algebra can be used to build a pervasively
lazy O/R framework.  I also suspect, however, that the optimal way of
using such a framework will be by expressing queries in relational terms
(as joins, projections and selections, as in SQL) rather than in object
graph terms.

Ok, ramble mode off.
Avi