On 11/4/06, Mark Ramm <[EMAIL PROTECTED]> 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. > I totally agree object databases should have their own storage engine and that is their main problem right now mostly because we have years of enginieering on top of relational databases that makes any object db look slow.
trying to create a full blown Object db on top of a relational database to the day has result in failures. specially went you need to do something like "full text searches" and queries in general. > 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. > exactly the goal of SQLObject and all the declarative layers on top of SA is to make an abstraction of the SQL layer into a python object, which is diferent then a OODB > --Mark > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
