[Seaside] database and eomodel

[Alain Fischer]

Yes, I like your approach of relational algebra, it seem interesting.
I will try Roe once my proof of concept has been done.

An other approach that I have read about and that seem very interesting
is Prolog - SQL. The where clause of SQL seem very close to Prolog.

Alain


Le Dimanche 13 avril 2003, à 11:52 , Avi Bryant a écrit :

>
> 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
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>