Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Modified statements in "before_cursor_executes" break SQLite update assertions w/ declarative_base [1.2.14] #4396
Comments
|
SQLAlchemy doesn't calculate that rowcount, the driver does, so this is a sqlite3 bug that should be posted to bugs.python.org. It is a common technique in the sqlite3 driver that they parse SQL statements in order to determine if certain actions should be taken, an example of a previous issue with this is https://bugs.python.org/issue21718. So for this issue, here's the test case: import sqlite3
conn = sqlite3.connect(":memory:")
cursor = conn.cursor()
cursor.execute("""
CREATE TABLE foo (
id INTEGER NOT NULL,
updated_at DATETIME,
PRIMARY KEY (id)
)
""")
cursor.execute("""
/* watermarking bug */
INSERT INTO foo (id, updated_at) VALUES (?, ?)
""", [1, None])
cursor.execute("""
UPDATE foo SET updated_at=? WHERE foo.id = ?
""", ('2018-12-02 14:55:57.169785', 1))
assert cursor.rowcount == 1
cursor.execute("""
/* watermarking bug */
UPDATE foo SET updated_at=? WHERE foo.id = ?
""", ('2018-12-03 14:55:57.169785', 1))
assert cursor.rowcount == 1
for workaround here, turn off the "sane rowcount" flag of the dialect to disable these checks: engine = sqlalchemy.create_engine('sqlite://', echo=True)
engine.dialect.supports_sane_rowcount = False
engine.dialect.supports_sane_multi_rowcount = False # for executemany() |
|
please forward to bugs.python.org and use that workaround for now, there's no other action to be taken on this end, reopen if necessary. thanks! |
|
Thank you. I've reported upstream: |
If you return a modified version of the sql statement in a
before_cursor_executeevent,UPDATEs to models will fail against SQLite, but not against other RDBMs like Postgres.It's common to add watermarking comments to all queries that explain the origin for use during debugging/load optimization. e.g.
Complete failure example:
results in a failed row count update assertion: