- attached testCompositeMutablePK.py
Mutable primary keys of composite column type are broken
I've encountered a problem with composite column types and mutable primary keys. When a primary key is updated and flushed, the row to update is identified by the historical value of the primary keys, that is, the value of the primary keys in their stored state. The primary key values are identified by the code snippet below from mappers.py; params holds the values used to create the WHERE statement:
...
if col in pks:
if deleted:
params[col._label](col._label) = deleted[0](0)
...
However, if the primary key is part of a composite property, this statement incorrectly adds the class 'containing' the composite values (the attached test case illustrates this problem). Instead, we need to extract the value from the composite type, i.e.
...
if col in pks:
if deleted:
params[col._label](col._label) = prop.get_col_value(col, deleted[0](0))
...
I've attached patches for the 0.4 and 0.5 branches.
ps. I haven't yet written a test case, but I'm also suspicious about how the lines immediately following this patch will handle composite column types:
...
else:
params[col._label](col._label) = added[0](0)
...
Maybe this should also be altered to use prop.get_col_value? Changing this to prop.get_col_value(col, added0) doesn't cause any unit test regressions..
Comments (7)
-
Account Deleted -
Account Deleted - attached compositePK-sa4.patch
Patch for 0.4 branch
-
Account Deleted - attached testCompositeMutablePK.tar
Tar containing test code and patches for 0.4 and 0.5 branches
-
Account Deleted - attached compositePK-sa5.patch
Patch for 0.5 branch
-
repo owner great patch, will try to commit sometime tomorrow. thanks !
-
repo owner - changed status to resolved
-
repo owner - removed milestone
Removing milestone: 0.5.0 (automated comment)
- Log in to comment
Test case