[DB-SIG] Improved support for prepared SQL statements

M.-A. Lemburg mal at egenix.com
Wed Dec 17 22:02:42 CET 2014


On 17.12.2014 18:54, Michael Bayer wrote:
> 
>> On Dec 17, 2014, at 10:41 AM, M.-A. Lemburg <mal at 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.

You're right: it depends on how you read "ORM" :-)

If you mean: mapping Python objects to relational database,
then yes, we always do that, since even an integer is a Python
object.

What I usually refer to as "ORM", and meant in the above
paragraph, is the approach of using methods and (special)
attributes on objects to build and run SQL queries behind
the scenes, with the main intent of abstracting away the SQL.

>>> 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.    

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 17 2014)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-12-11: Released mxODBC Plone/Zope DA 2.2.0   http://egenix.com/go67

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the DB-SIG mailing list