[Seaside] Automatic Object Storage To MySQL
seaside at harford.org
Wed Jan 25 23:34:19 CET 2006
On 25-Jan-06, at 4:23 PM, Lukas Renggli wrote:
> I wonder why you are trying to guess the i-vars? Wouldn't it be much
> more powerful to have a meta-model (like Magritte) where you could
> specify what and how to store the values of a model? I think the code
> could also benefit from a propre description, so that you could avoid
> all those long manual type-checks with the nested #ifThen: clauses.
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.
It might be nice if the developer could easily do either or. So
either have the library determine how to store the i-var or allow the
developer to direct the library. That might give us the best of both
worlds (or the worst).
I agree that the current method of determining the type and saving to
the database is kludgey and should be improved. Suggestion?
> What about the performance of your library?
Well it's early but so far the performance has been adequate and the
one application I ported to this library performed much better than
I would think at this point large arrays particularly arrays of
IOSPersistent objects do to the fact that they must all be resolved
when the object is resolved. Large trees of object would also be a
problem but this is on the top of my list to resolve.
I would also add that I think it's ok to trade more than some
computing performance for programmer performance. It's usualy cheeper
to through hardware at the problem than it is to through programmers
or programming time at the problem.
You milage may vary.
> Lukas Renggli
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside