[Seaside] About SToR
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
> 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
> in RDBMSes at best. Trees, custom data-structures, even the whole
> concept of
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?
More information about the Seaside