[Seaside] Re: Automatic Object Storage To MySQL
yanni at rogers.com
Thu Jan 26 02:40:22 CET 2006
William Harford wrote:
> On of the core ideas of the project is to limit the amount of work a
> developer has to do. The deveolper should only have to be minimally
> aware of how the object is being stored. Think of it this way. The
> developer has already defined the class why should she have to define
> the way the class is stored. The library should be able to figure out
> how to store the object with out any input from the developer other
> than the class definition. While the library code would benefit by
> offloading some work onto the developer it's my position that the
> developer would not.
I recently watched the Ruby on Rails movie, and AFAICT
it seems to read the database each time the system runs,
to generate the needed meta-data. So the question arises:
which should be the canonical definition - the database
or the code?
Like you, I've been going from conceptual model, to code,
to database. In this case, if I change the model, I have
to figure out how to migrate the database tables and the
existing data records. In Rails, one seems to manually alter
the database, then figure out how to make the code adapt
(only the parts that aren't automatically fixed need work).
> I agree that the current method of determining the type and saving to
> the database is kludgey and should be improved. Suggestion?
I agree with Lukas - use meta-data. The question is where to
put it (without altering Class/Behaviour to make space).
Currently, I use a class method, but I'd like something
lighter-weight. So, I've been thinking of doing something
like Monticello, which just puts rules on the category names.
In this case, the instance variable names would have a type suffix.
That feels kind of ugly, though. Maybe the accessors could
have the suffix stripped off.
More information about the Seaside