[Seaside] database and eomodel

[Benoit St-Jean]

--- Avi Bryant <avi at beta4.com> wrote:
> 
> 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.


Well...  The problem you just described above was not
an issue with TOPLink (didn't check for GLORP though)
when you used cursored streams, cursored collection
and  in the case specified above, virtual collections...

=====
-------------------------
Benoit St-Jean
bstjean at yahoo.com
Yahoo! Messenger: bstjean
http://cactus.swiki.net
-------------------------