regression in bulk update, evaluator disallows literal_column
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class A(Base):
__tablename__ = 'a'
id = Column(Integer, primary_key=True)
x = Column(Integer)
y = Column(Integer)
e = create_engine("sqlite://", echo=True)
Base.metadata.create_all(e)
s = Session(e)
s.add(A(x=1, y=2))
s.commit()
s.query(A).update({A.x: literal_column('y')})
result:
#!
Traceback (most recent call last):
File "test.py", line 22, in <module>
s.query(A).update({A.x: literal_column('y')})
File "/home/classic/dev/sqlalchemy/lib/sqlalchemy/orm/query.py", line 3366, in update
update_op.exec_()
File "/home/classic/dev/sqlalchemy/lib/sqlalchemy/orm/persistence.py", line 1324, in exec_
self._do_pre_synchronize()
File "/home/classic/dev/sqlalchemy/lib/sqlalchemy/orm/persistence.py", line 1399, in _do_pre_synchronize
"Could not evaluate current criteria in Python. "
sqlalchemy.exc.InvalidRequestError: Could not evaluate current criteria in Python. Specify 'fetch' or False for the synchronize_session parameter.
this affects openstack nova and the soft_delete() method in oslo.db which uses this.
Comments (2)
-
reporter -
reporter - changed status to resolved
Warn instead of raise for unmapped column that matches on key
Modified the change made to the ORM update/delete evaluator in
3366
such that if an unmapped column expression is present in the update or delete, if the evaluator can match its name to the mapped columns of the target class, a warning is emitted, rather than raising UnevaluatableError. This is essentially the pre-1.2 behavior, and is to allow migration for applications that are currently relying upon this pattern. However, if the given attribute name cannot be matched to the columns of the mapper, the UnevaluatableError is still raised, which is what was fixed in3366
.Change-Id: I658ed0dbf485b7f8009774f9c12d9912447abd2a Fixes:
#4073→ <<cset db170dd4529c>>
- Log in to comment
the change was 63a7b2d2d9402b06f9bc7745eed2d98ae9f8b11c /
#3366where we tried to make this stricter.