As I said before, prepared statement is normally bound to connection.
So `.prepare()` method should be connection's method, not cursor's.
prepared = conn.prepare("SELECT ?+?")
...
cur = conn.cursor()
cur.execute(prepared, (1, 2))
cur.fetchone() # returns (3,)
On Thu, Dec 18, 2014 at 2:54 AM, Michael Bayer <mike...@zzzcomputing.com> wrote:
>
>> 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
--
INADA Naoki <songofaca...@gmail.com>
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
