the pysqlite driver does not deliver SERIALIZABLE isolation in its default mode
of use. you have to use workarounds to achieve this. See the documentation at
https://docs.sqlalchemy.org/en/20/dialects/sqlite.html#serializable-isolation-savepoints-transactional-ddl
which details how to use thes
Summary:
The SQLAlchemy SQLite dialect does not fully support serializable
transaction isolation in SQLite, leading to potential invalid data when
transactions interleave.
Hello,
This report documents an issue with transaction integrity in the
SQLAlchemy SQLite dialect.
SQLite itself is able
the deprecation warning is from the SQLAlchemy side and we need to remove it
which will be for 1.4.
Also we've identified a bug in cx_Oracle in this area that's not fixed yet, a
cx_Oracle 2pc transaction cannot be replaced by a non-2pc transaction on a
single connection:
https://github.com/ora
Hi Mike,
I'm effectively using cx-Oracle... but I didn't notice any deprecation
warning! Maybe it's because I'm still using release 8.0.1 (as I still need
Python 3.5 support)?
If you need anyone to test for cx-Oracle features, just ask!
Anyway, I'm also using other "no-transactional" databases (l
FWIW, within the realm of pyramid_tm, the more common use-cases for
two-phase transaction support are for sending mail and a dealing with task
queues - not two separate databases.
On Wednesday, January 27, 2021 at 2:40:21 PM UTC-5 Mike Bayer wrote:
>
>
> On Wed, Jan 27, 2021, at 2:23 PM, Thierr
On Wed, Jan 27, 2021, at 2:23 PM, Thierry Florac wrote:
> Hi,
> I'm actually using two databases connections: one is my "main" connection,
> opened on a ZODB (with RelStorage), and **sometimes** I have to open another
> connection on another database (and event more sometimes); the two
> trans
Hi,
I'm actually using two databases connections: one is my "main" connection,
opened on a ZODB (with RelStorage), and **sometimes** I have to open
another connection on another database (and event more sometimes); the two
transactions have to be synchronized: if one of them is aborted for any
reas
On Wed, Jan 27, 2021, at 8:32 AM, Thierry Florac wrote:
>
> Hi,
> I'm actually using SQLAlchemy with Pyramid and zope.sqlalchemy packages.
> My main database connection is a ZODB connection and, when required, I create
> an SQLAlchemy session which is joined to main transaction using this kind
Thierry,
Would you mind putting together a test-case on this? I haven't experienced
that before, and I authored that feature in the debugtoolbar. If I can
recreate it, I'll put together a fix and work with the pyramid team to get
a new release out asap.
On Wednesday, January 27, 2021 at 8:32
Hi,
I'm actually using SQLAlchemy with Pyramid and zope.sqlalchemy packages.
My main database connection is a ZODB connection and, when required, I
create an SQLAlchemy session which is joined to main transaction using this
kind of code:
from sqlalchemy.orm import scoped_session, sessionmaker
Hi,
I have a question regarding multi-threading and transactions in the non-ORM
case.
Assume, we have a global Connection c (with transaction), on which a number
of insert/update queries are executed and some insert/update queries are
executed in threads:
Main thread: Thre
this will need lots more work on my end and may not be possible without major
caveats. once you use connection.begin(*xid), the cx_oracle connection goes
into a new mode that seems to render the usual DBAPI contract of "implicit
begin" permanently broken. I've spent about three hours trying t
On Nov 21, 2012, at 5:32 AM, Thierry Florac wrote:
> Hi Michael,
>
> I applied your patch on my current SA 0.7.3 without any problem, and added a
> few traces. Everything seems to work perfectly!
>
> Here is the first output with updates:
>
> >>> do_begin_twophase
> >>> do_prepare_twophase
Hi Michael,
I applied your patch on my current SA 0.7.3 without any problem, and added
a few traces. Everything seems to work perfectly!
Here is the first output with updates:
>>> do_begin_twophase
>>> do_prepare_twophase = True
>>> do_commit_twophase
> oci_prepared = True
> do_commit
great. can you try the attached patch please (latest 0.8 tip), which will not
call "commit" if the "prepare" returned false. I'm not sure if this is
complete though, if we should be doing a "rollback" afterwards, or what.
not sure if I can get my local oracle XE to do two phase for real, t
Hi Michael,
Following your guidelines, this is the first test I made against cx_Oracle :
>>> conn = cx_Oracle.connect('scott','tiger','localhost:1521/ORCL',
twophase=True)
>>> id = random.randint(0, 2 ** 128)
>>> xid = (0x1234, "%032x" % id, "%032x" % 9)
>>> conn.begin(*xid)
>>> conn.prepare()
Fa
Googling for the ORA code yields the usual tautological answers that say
nothing.
The first step here would be to isolate the issue in a simple test case with
SQLAlchemy only, and then cx_oracle where I suspect the bug lies.
The Session will not create a transaction at all, if no SQL is emitted
Hi Michael,
This is a complete traceback produced by removing my checking code against
attribute modification.
Original code is then as simple as this:
@ajax.handler
def updateOrderMenuItemBO(self):
session = getSession(SESSION_NAME)
ids = [ int(id) for id in self.request.
On Nov 19, 2012, at 6:23 PM, Thierry Florac wrote:
> As far as I can understand it, I'm globally OK with you but... probably
> not completely :-\
> I agree with the fact that SQLAlchemy is not the only package which
> takes part into the global transaction, as SA's session is handled by a
> Zope
Le Mon, 19 Nov 2012 10:23:14 -0500,
Michael Bayer a écrit:
> On Nov 19, 2012, at 8:10 AM, Thierry Florac wrote:
>
> > Hi,
> >
> > I'm using SQLALchemy (currently 0.7.3 in this project, also tested
> > with 0.7.9) with cx_Oracle-5.1.1 in a Zope3 project. SQLAlchemy
> > transactions are handled
On Nov 19, 2012, at 8:10 AM, Thierry Florac wrote:
> Hi,
>
> I'm using SQLALchemy (currently 0.7.3 in this project, also tested with
> 0.7.9) with cx_Oracle-5.1.1 in a Zope3 project.
> SQLAlchemy transactions are handled in two-phase with
> ZopeTransactionExtension.
>
> My problem is quite si
Hi,
I'm using SQLALchemy (currently 0.7.3 in this project, also tested with
0.7.9) with cx_Oracle-5.1.1 in a Zope3 project.
SQLAlchemy transactions are handled in two-phase with
ZopeTransactionExtension.
My problem is quite simple : in a form, I can order several items which
updates an "index"
giant transaction --
2011-05-08 15:22:48,857 INFO sqlalchemy.engine.base.Engine.0x...9aac
BEGIN (implicit)
2011-05-08 15:22:48,865 INFO sqlalchemy.engine.base.Engine.0x...9aac
SELECT ...
Is there a way to disable SQLAlchemy transaction or at least make them
only applicable to small regions of
That doesn't sound right. Session.commit() issues the commit regardless of
whether or not flush() had any work to do. The usage of Session.execute()
takes place in the scope of the Session's transaction so work is definitely
begun as well.
from sqlalchemy import create_engine
from sqlalchem
From time to time I find I need or prefer "dropping into SQL" for
certain tasks, in the midst of making the majority of my database
changes through sqlalchemy's objects; for example, I may use
session.execute(sql).
I would like these changes to be committed later along with the sqla
session ob
I'm aware that create_engine() supports an 'isolation_level' argument
for setting the transaction isolation level. However - searching the
online documentation for "isolation_level" only gets hits for
PostgreSQL and Sqlite, though...
http://www.sqlalchemy.org/docs/search.html?q=isolation_level
I
Hi,
I have a problem about transaction object. How can I obtain the data
which will committed, but didn't main transaction?
So, I have two methods. The first start transaction (trans = conn.begin
()) and connection object will be input parameter to another method.
However, this new method can cha
Hello,
I'm running into a hang case on issuing an INSERT to mysql. Here's
some code. Note that I don't really use sqlalchemy sessions or query
objects or anything, I've written my own...I'm only using sqlalchemy
for connection management. So in some file foo.py, I have the
following:
All of t
Hi,
I am having problems getting transactions working.
I am calling conn.begin() but before I call trans.commit(), something
else commits for me.
It is committing right after I do the job_insert.execute(). Can someone
shed some light.
Many Thanks
Huy
I have the following code
trans
Hi all,
I'm trying to mix ORM transactions and SQL transaction as follows:
T1 = S.create_transaction()
# do some ORM stuff
C1 = T1.connection()
C2.execute(sql)
T2 = S.create_transaction()
# nested ORM stuff
C2 = T2.connection()
C2.execute(sql)
30 matches
Mail list logo
