Mark Ramm wrote: > > Of course it's not ther (especially Object Orientation). > > > > And seeing the reply-behaviour within this project I think I understand > > why. > > TurboEntity is is definitely more OO oriented than SQLOriented. I > think that's what Jorge was talking about. It's likely not exactly > what you want, but it provides a basic OO layer on top of SQL. > > If you want full OO, with a data store in SQL, and no configuration > work there are other projects to look at. But I personally am not > convinced that there's the advantages to keeping Object Database data > in a relational database are worth the cost of the extra layer. I'm > certainly willing to be proved wrong on this, but I think Object > Databases should be free to define their own data storage method. > > The point of all this is that we want the declarative layer in > SQLAlchemy to provide a smooth upgrade path from SQLObject, not to > emulate an OODB.
projects should really look a little at other implementations: http://db.apache.org/ojb/ Providing a _standard_ OO interface is the most important need for the whol python domain. The turbogears project would benefit from a possible upgrade path to large-scale commercial ODBMS. http://odbms.org/ . --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
