Re: Automatic Object Storage To MySQL

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

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.

Thanks Will

> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> Seaside@xxxxxxxxxxxxxxxxxxxxxxxxxx
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside