John M Camara wrote: > > > On Jan 25, 9:59 pm, Leandro Lucarella <[EMAIL PROTECTED]> wrote: >> Well, this is not the only approach. Another approach is to think you just >> have objects in you app, and the persistence is just an accident. You >> store your data in a relational database just because is the best way (is >> it? ;) > You may actual need an object orient database instead of a relational > one. If this is the case than SO or SA are inappropriate and would > explain why you are getting frustrated and having to add hacks. But > unless you post details of what your trying to do this is just > speculation. > > If you don't want to post details I suggest you take a look a Durus - > http://www.mems-exchange.org/software/durus/ to see if it meets your > needs better than a relational database. >
I think offering the use of OODBMS would be a good idea if their state was in a better shape. Having a storage like Durus is a good thing but is it enough? Do you have any standard query language? How do you export your data? Can you make statistics on your data? OODMBS in the Python World are pretty basic and don't fit the bill unless you're ready to write your own tools for most of those tasks. I personally have gone for dejavu [1] after trying SA and SO for some of the reason Leandro described. I don't like ORM because on the long run for large project I believe they tend to create more difficulties (flexibility, design, performance) than they solve problems. I definitely don't like the fact that SA and SO don't hide from the developer point of view that they are dealing with RDBMS (type mapping, method and function naming, querying approach). I enjoy dejavu more for the precise reason that this is the first ORM I use that actually hides that fact from me while providing the same level of features. * dejavu type mapping is based on Python types not SQL ones which makes my life easier throughout the rest of my application. * dejavu querying system is based on pure Python lambda expression * dejavu hides the notion of RDBMS by not introducing in its nomenclature terms from RDBM. So you handle Units within sandboxes which are themselves part of an arena. That arena is your interface to the underlying storage. Where SA discusses tables and rows. Don't get me wrong I have no doubts SA and SO are powerful ORM and they seem to suit well lots and lots of people but there are some developers who can't adapt themselves to the ORM and wish the ORM could actually bend as any other library taking part in an application as the design requires. Unfortunately to my liking SA and SO forces you to adapt your design to theirs and I don't like that. (Of course this is extremely subjective so don't flame me ;)) In any case of course it's a matter of taste and I'm not trying to say dejavu is the king and SA/SO are rubbish. No. What I'm saying is that alternatives exist and are sometimes more suitable. - Sylvain [1] http://mail.python.org/pipermail/python-announce-list/2007-January/005581.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
