Michael Bayer wrote: > well, I am all in favor of projects basing themselves on SA, and if it > also means that ActiveMapper will be improved/documented, thats just > great. SA also aims to be as open as possible to extensions of its > functionality (but importantly, while keeping specialized concepts and > usage scenarios out of the core code).
ok, sounds rational. > I would note that the concept of a pure "OO" layer over RDBMS is > somewhat in conflict with the philosophy of SA, which states that the > "object/relational impedance mismatch" is a real thing that cant be > ignored (but does say that there is hope). Also its true that SA does > provide services that go a long way towards being able to "ignore" the > database side of things, but it intentionally does not go all the way > (there are a few cases where we might go a little futher). ok > I did have a notion of building an "object" query language on top of > the ORM where you would deal specifically with class/atttribute > constructs rather than Column/Clause constructs; this would require a > new set of expression objects with some resemblence to ClauseElement > objects. But that all assumes we're still going with the "DSL" type of > system; Hibernate in contrast uses HQL which is string-based. If such > a system were constructed it could be an optional extension to > SQLAlchemy's ORM (but it really would need dedicated maintainers, as I > am stretched to the limit with the current functionality). There are standards available for OQL. > Also, while SA does include three general systems, the SQL construction > language, the connection/execution engine, and the ORM, thats probably > as far as it will go as far as "core" functionality. There has been > some critique that it even bundles a SQL construction language and ORM > together. The ORM is not meant to be the "only" possible ORM and SA > invites other ORM projects to construct on top of the SQL > language/execution system. I've understood that SA can be used to produce an SQLObject compatible layer: http://groups.google.com/group/turbogears/browse_thread/thread/89dc84b2e9d9d860 maybe you have some comments to this thread. > Depending on what youre looking to achieve > you might find ActiveMapper to be at too high of a level (in fact this > is likely....youd probably end up creating your own "metaclass" layer > on top of the basic mapper if your project is reasonably ambitious, as > these layers are not very hard to construct). the ODMG layer would have the main goal to allow migration to a real ODBMS which uses the ODMG API. Of course, this layer would possibly emmit some requirements to SA. > > - mike > > Ilias Lazaridis wrote: > > I have several difficulties in selecting a persistence subsystem for > > python. > > > > As things look at this point, the most rational step seems to be to > > implement an OO layer (limited subset of ODMG [1]) for SQLAlchemy. > > > > I would possibly start such a project, but would like to know if the > > SQLAlchemy project would support such efforts. > > > > ActiveMapper could possibly serve as a foundation for this (or efforts > > can be synchronized). > > > > Please let me know your thougts. > > > > http://case.lazaridis.com/wiki/Persist > > > > . > > > > [1] > > http://www.odmg.org/ > > http://www.odbms.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~----------~----~----~----~------~----~------~--~---
