- changed status to duplicate
Problem with Binary column as a primary key and the session cache
Issue #1536
resolved
Running the following code gives the following error. I tried to make it as small as possible.
import sqlalchemy
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from sqlalchemy import create_engine, Column, Binary
Base = declarative_base()
class Blob(Base):
__tablename__ = "blob"
b = Column(Binary, primary_key=True)
def __init__(self):
self.b = "abcd"
if __name__ == "__main__":
engine = create_engine("sqlite://")
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)
s = Session()
s.add(Blob())
s.commit()
print repr(s.query(Blob).first().b)
c:\backend>test.py
Traceback (most recent call last):
File "c:\backend\test.py", line 21, in <module>
print repr(s.query(Blob).first().b)
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\query.py", line 1231, in first
ret = list(self[0:1](0:1))
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\query.py", line 1152, in __getitem__
return list(res)
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\query.py", line 1353, in instances
rows = [process[0](process[0)(context, row) for row in fetch]
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\query.py", line 1955, in main
return _instance(row, None)
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\mapper.py", line 1614, in _instance
if identitykey in session_identity_map:
File "C:\software\python25\Lib\site-packages\sqlalchemy\orm\identity.py", line 95, in __contains__
if dict.__contains__(self, key):
TypeError: writable buffers are not hashable
When I change the column definition from
b = Column(Binary, primary_key=True)
to
id = Column(Integer, primary_key=True)
b = Column(Binary)
the error goes away. It seems that the Binary column is converted to a buffer object and the orm tries to use it as a key for a regular dict.
Comments (1)
-
repo owner - Log in to comment
this is fixed for 0.6 as described in
#1524. See that ticket for a workaround using 0.5.