I've noticed that if a transaction fails midway through, objects that
already have been inserted will have their primary keys set, even after
rolling back.
Partial snippet below:
-----
class User(Base):
id = Column(Integer, primary_key=True)
name = Column(String(80), unique=True, nullable=False)
alice = User(name="alice") # primary key is not set
bob = User(id=1, name="bob") # primary key set to clash with alice
session.add(alice)
session.add(bob) # note bob is added second here so that the commit fails
part-way through
print(alice, bob) # <User(name='alice', id='None')> <User(name='bob',
id='1')>
try:
session.commit() # will fail with IntegrityError
except:
session.rollback()
print(alice, bob) # <User(name='alice', id='1')> <User(name='bob', id='1')>
------
Note that in the above snippet, Alice's primary key is set after the
transaction rollback. This is annoying since adding alice to another
session will cause her to use the primary key that was set for her rather
than an automatically generated one, as you might expect.
Is this the intended behavior, is my mental model wrong, or is this a bug?
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
