[Seaside] About SToR

[Colin Putney]

On Jul 28, 2006, at 11:17 AM, Benjamin Pollack wrote:

> On 7/28/06, Wilkes Joiner <wilkesjoiner at gmail.com> wrote:
> I've been doing some Rails work lately.  ActiveRecord is really nice,
> and Migrations are fantastic.  Porting ActiveRecord to squeak and
> providing browser support for it seems like a slam dunk to me.  I
> wouldn't do a straight port but just borough the main concepts.
>
> I'm still not convinced this is a good idea.
>
> ActiveRecord is trying to solve a simple problem at its base: how  
> can we persist massive collections of objects in Ruby? The answer  
> they arrived at was to use an RDBMS for persistence, and then to  
> adopt the same translation concept as a dozen other frameworks have  
> tried: tables to classes, rows to objects, columns to instance  
> variables. The problem is that this mapping does not make sense. It  
> breaks the object model in subtle and not-so-subtle ways that  
> ultimately become extraordinarily aggravating.

Hi folks,

Having wrestled with this problem before, I'll add a data point to  
each side here:

For those show want to store objects in a relational database,  
Tantalus might be worth a look. It's probably not usable off the  
shelf, as it was written for Squeak 3.2, but it might provide a ideas  
and code for some new framework.

On the other hand, I have to agree with Benjamin. Storing objects as  
rows works reasonably well for simple cases, but it breaks down  
awfully quickly when your object models start to get more complex  
than collections.

On top of that, there's another, more subtle mismatch when Seaside is  
involved. Seaside wants objects to have long lifecycles. It tends to  
hang on to objects in component instance variables, link and form  
callbacks, and session-wide state. Even "temporary" variables tend to  
live a long time, since continuations can be retrieved and reentered  
minutes or hours after they were captured.

Databases, on the other hand want transactions to be short. "Long  
transactions" are a classic problem to avoid in the database world.  
This means that the O/R mapping layer has to be very careful about  
caching, managing the state of persistent objects, and detecting  
conflicts. It gets really tricky when you have Seaside trying to keep  
objects in sync with the browser on the front end, and the  
persistence layer trying to keep them in sync with the database on  
the back end.

All this is not to say that O/R mapping can't be done, but I think  
it's almost impossible to do it in a way that's general enough for a  
wide range of applications, yet seamless and transparent for the  
developer. The only place I've seen it work well was when it was not  
transparent at all, but built in to the application and carefully  
crafted to have the behavior required by the application.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20060728/c262758d/attachment-0001.htm