> On Dec 17, 2014, at 10:41 AM, M.-A. Lemburg <m...@egenix.com> wrote: > > > Another possibility is to write a layer on top of the DB-API > to abstract the underlying queries away from the application > and only have the layer provide dedicated methods for the > things the application needs, such as query method for specific > details or inserting application objects into the database. > > This is the approach we usually take in our projects, since > it provides better separation of the application logic from the > database logic than using ORMs usually provides. It's also possible > to use such an abstraction layer on top of an ORM, if you want > to the ORM to deal with abstracting away database backend details.
When I read this quickly, it seems to make sense, but when I really try to imagine what this means, I come out at the same place every time: if you’ve written a “method for inserting application objects into the database”, you’ve written an ORM. Databases don’t store “application objects”, they store rows. So there has to be “ORM” in there. >> >> I am looking for higher service levels without following the software >> design directions from object-relational managers like SQLAlchemy >> and SQLObject. replying to Markus - SQLAlchemy’s ORM is only an optional component of the SQLAlchemy database toolkit overall. If you would like a very mature and well proven SQL abstraction layer that does not provide any design directions whatsoever (not to mention much better performance than the ORM), please consider SQLAlchemy Core: http://docs.sqlalchemy.org/en/rel_0_9/core/index.html. _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
