[Seaside] About SToR
cputney at wiresong.ca
Fri Jul 28 16:36:21 UTC 2006
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.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside