[Seaside] About SToR

Richard Huxton dev at archonet.com
Fri Jul 28 15:58:20 UTC 2006

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.
> 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. 

Treating an RDBMS as an object persistence store does indeed cause 
problems. At the core is the fact that an RDBMS is about data and 
objects are about behaviour. The RDBMS is supposed to be an 
application-neutral store of relevant business-related facts, whereas 
your objects are (hopefully) structured in a manner that is convenient 
for your application.

For myself I've been working at things from the other direction. 
Object-oriented systems are good at modelling things, so I've been 
building a model of the database. A proper one, not ActiveRecord.

I have classes to model the DB, relation defintions, relations 
themselves (whether a whole table or query results), attributes, 
attribute types, default values, foreign-keys, multi-column primary keys 
etc. With a little meta-data from the comments in the DB (I'm working 
with PostgreSQL) it knows the human-readable names of tables, views, 
attributes etc. Oh, and which attribute(s) can be used to describe a 
particular row (e.g. first_name, last_name).

Tuples have a concept of old and new values, so you can have validation 
on individual attributes or the tuple as a whole. Oh, and attributes are 
accessed by name (myTuple at: 'id') not as separate member functions.

I still have a fair bit of work to do with constraints, and to 
automatically generate the definitions from my database parser (in Perl).

Then, I need to have a proper look at ROE and see what I can steal^W 
integrate from that - the querying looks very nice.

Would anyone else be interested in this if I can get the time to tidy it 
up and make it presentable?

   Richard Huxton
   Archonet Ltd

More information about the Seaside mailing list