Thanks a lot for bearing with me.
explicit execution - uses a Connection, but will autocommit
conn = engine.connect()
conn.execute(insert into table (a, b, c) values (1, 2, 3))
I still want a clarification about the above case. When we use
explicit execution like the
On Jan 24, 2011, at 5:46 AM, bool wrote:
Thanks a lot for bearing with me.
explicit execution - uses a Connection, but will autocommit
conn = engine.connect()
conn.execute(insert into table (a, b, c) values (1, 2, 3))
I still want a clarification about the above
I am not an expert in these concepts, so just trying to make sure I
understand what you said.
1. If I use connection.execute(), then then every sql statements is
not put in its own transactions.
2. But If I use connection-less execution like table.execute or
engine.execute() then every statement
On Jan 21, 2011, at 9:16 AM, bool wrote:
I am not an expert in these concepts, so just trying to make sure I
understand what you said.
1. If I use connection.execute(), then then every sql statements is
not put in its own transactions.
2. But If I use connection-less execution like
On Jan 20, 2011, at 2:04 AM, bool wrote:
If I dont use autocommit:True option, it seems the driver will be in a
chained transaction mode and results in every single statement
(including selects) being run in a new transaction. This is not
desirable either.
Is there a way out ?
The
If I dont use autocommit:True option, it seems the driver will be in a
chained transaction mode and results in every single statement
(including selects) being run in a new transaction. This is not
desirable either.
Is there a way out ?
--
You received this message because you are subscribed
I have put a self contained script that can probably reproduce this
for you. I think that the argument 'connect_args': {'autocommit' :
True } is causing the transactions to not work properly. Is this
expected and if so can you explain the reason. Thanks in advance.
that is absolutely the reason transactions would not be working for you.
autocommit on the DBAPI essentially makes the commit() and rollback() methods
of the DBAPI connection a no-op.
On Jan 18, 2011, at 5:12 AM, bool wrote:
I have put a self contained script that can probably reproduce
FYI I am using sqlserver 2008 and sqlalchemy 0.5
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
ie: I expect nesting behaviour like in MatthieuF's response here for
SQLServer:
http://stackoverflow.com/questions/527855/nested-transactions-in-sql-...
OK, that's a behavior specific to stored procedures in SQL server, not one I
was aware of. To my knowledge, a nested transaction is not
Thanks... I don't think my question stemmed from a lack of reading the
extensive sqlalchemy documentation, but more of a limitation on my
understanding of how sqlite works (or doesn't) with nested
transactions. I know that you need the SingletonThreadPool or nested
sessions completely block on
On Oct 18, 2010, at 3:10 PM, Russell Warren wrote:
Thanks... I don't think my question stemmed from a lack of reading the
extensive sqlalchemy documentation, but more of a limitation on my
understanding of how sqlite works (or doesn't) with nested
transactions. I know that you need the
12 matches
Mail list logo
