The SQLAlchemy implementation of CrateDB's OBJECT type offers indexed access to the instance's content in form of a dictionary. Thus, it must not use cache_ok = True on its implementation, i.e. to signal this part of the compiled SQL clause must not be cached.
Problem
Currently, when using those statements subsequently, based on a corresponding ORM schema definition, the second one will yield the wrong results, because it will use the compiled SQL statement of the first one, as it has been cached wrongly. This flaw has been reported by @faymarie, thank you very much.
class Character(Base):
__tablename__ = 'characters'
name = sa.Column(sa.String, primary_key=True)
age = sa.Column(sa.Integer)
data = sa.Column(Object)
The accompanying test case verifies that two subsequent SELECT statements are translated well, and don't trip on incorrect SQL compiled statement caching. Because I have not been able to catch that error by unit tests based on mocking, this test case has now been introduced as a first integration test to the SQLAlchemy dialect subsystem.
About
The SQLAlchemy implementation of CrateDB's
OBJECTtype offers indexed access to the instance's content in form of a dictionary. Thus, it must not usecache_ok = Trueon its implementation, i.e. to signal this part of the compiled SQL clause must not be cached.Problem
Currently, when using those statements subsequently, based on a corresponding ORM schema definition, the second one will yield the wrong results, because it will use the compiled SQL statement of the first one, as it has been cached wrongly. This flaw has been reported by @faymarie, thank you very much.
Details
The accompanying test case verifies that two subsequent
SELECTstatements are translated well, and don't trip on incorrect SQL compiled statement caching. Because I have not been able to catch that error by unit tests based on mocking, this test case has now been introduced as a first integration test to the SQLAlchemy dialect subsystem.