Thanks for the tips, however I mean this DB we have is pure objects,
there are no tables. So there isn't much of a logical leap to strap
python on top of it, however you can't use and SQL. I guess I was
wondering how tied to SQL SA is? If it's fundamental to the core, then
I'm out of luck. But it different engines can supply their own
navigation logic, then it might be worthwhile.
On Feb 9, 12:16 am, svilen [EMAIL PROTECTED] wrote:
how much OO u want?
There is SA, which has ORM layer over sql, so can become a somewhat
object persistency.
There are turboentity/activemapper, currently joining together, which
are simple declarative layer on top of SA.
Then here is this 'sawrapper' of mine, which is also declarative and
wider/deeper than them, automaticaly handling all inheritances /
decomposition and references and now able to convert plain python
funcs (of your objects) into SA clauses. It may join the above 2 one
day - if they wish.
Then i have another layer on top which adds protocol-like static-type
semantics...http://linuxteam.sistechnology.com/o2rm/sawrap0209.tar.bz2
None of them is 100% OO.
For a simple OOdbs, checkhttp://www.garret.ru/~knizhnik/compare.html
Has anyone tried making an engine for an OODB? My company is
heavily ties into Versant, and we'd love to use SQLAlchemy if
possible. Is this even a valid thought? Versant doesn't support
SQL, most of its calls are graph navigation. getchild(),
getparent(), getattr() etc...
Is this worth pursuing, and has anyone tried it?
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
