[Seaside] About SToR

[Benjamin Pollack]

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.

There are whole concepts easily expressed in OO that are painfully expressed
in RDBMSes at best. Trees, custom data-structures, even the whole concept of
subclasses. Some of these can be worked around--recursive queries in SQL 3
permit trees, most databases let you add new data-structure by writing
libraries in C, and subclasses usually can be expressed through a mix of
normalizing and repeating columns across tables--but it requires effor that
could be spent on getting things done, rather than simply figuring out how
to persist data.

Even Rails' migrations are a great example of a problem that RDBMSes have
that Squeak does not have to have. It's basically a version-control system
for the database. In Squeak, youcould simply use Monticello combined with
giving your class lazy initialization. Migrations are a band-aid over the
fact that relational models can't or don't express these concepts.

Rather than try to graft objects on top of the database, I greatly prefer
the idea started with ROE of bringing relational algebra to Squeak. ROE lets
you cleanly write relational queries within Squeak without resorting to SQL,
but deliberately makes no other attempt to unify the object and relational
worlds. Though I admit this is a slightly more Lisp-like solution, I also
strongly believe that it's the correct one.

If you're writing a new application, though, why use an RDBMS in the first
place? Why not figure out a way to truly persist objects? This is the
solution I would like to see more Squeak users adopt. We already have two
OODBMSes that we can reasonably use: GOODS, which is fast and well-tested,
and Magma, which is slow but gradually improving. Rather than spending time
vainly trying to get objects mapping to relational models, I'd rather spend
time improving our object databases until they become truly optimal
solutions for a wider class of problems.

Having said all of that, I do understand the need for an object-relational
mapper for legacy applications, but ActiveRecord is a bad model to follow
for a solution. ActiveRecord achieves its simplicity by strongly encouraging
the development of database schemas in a very particular way, and although
it is slowly gaining the flexibility to deal with schemas that do not follow
its preferred convention, there are many other frameworks--WebObject's
Enterprise Objects Framework being my favorite--that are much better
examples of legacy interfaces, if that's the route you wish to go.

I do think it would be wonderful if Seaside had a built-in persistence
mechanism as easily usable as Rails, but I would hope that the solution it
ends up adopting is not ActiveRecord.

--Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20060728/6d51a2c8/attachment.htm