Mutable primary keys of composite column type are broken

Issue #1213 resolved
Former user created an issue

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)

  1. Log in to comment