Optimistic locking fails if primary key is used in an ObjRelationship -- CAY-595

From: Mike Kienenberger (mkienen..mail.com)
Date: Wed Sep 13 2006 - 15:59:14 EDT

  • Next message: Andrus Adamchik: "Enabled issue linking in jira"

    I turned optimistic locking on for my 1.2.1 application, and updates
    started failing.

    I was getting output like the following where
    AUTHORIZATION_DOCUMENT_ID is the primary key.

    UPDATE ENG_WORK_MGMT.AUTHORIZATION_DOCUMENT SET PROJECT_NAME = ? WHERE
    AUTHORIZATION_DOCUMENT_ID IS NULL AND [...]

    The problem appears to be in
    org.objectstyle.cayenne.access.DataNodeSyncQualifierDescriptor.reset()

                            // relationship transformers override
    attribute transformers for
                            // meaningful FK's... why meanigful FKs can go
    out of sync is
                            // another story (CAY-595)
                            int index = attributes.indexOf(dbAttribute);
                            if (index >= 0 && !dbAttribute.isForeignKey()) {
                                continue;
                            }

    However, if there's an ObjRelationship to a dependent entity, this
    relationship transform will also replace the primary key transformer
    previously defined. [1]

    I changed it to

                            if (index >= 0 && (!dbAttribute.isForeignKey()
    || dbAttribute.isPrimaryKey())) {

    and the unit tests all seem to pass. I can't think of any reason to
    not use the primary key transformers in all cases.

    In fact, I'm wondering if it shouldn't simply be

                            if (dbAttribute.isPrimaryKey()) {
                                continue;
                            }
                            int index = attributes.indexOf(dbAttribute);
                            if (index >= 0 && !dbAttribute.isForeignKey()) {
                                continue;
                            }

    [1] Ie, I have a dependentPermitDocument relationship and a
    dependentEasementDocument relationship as both PermitDocument and
    EasementDocument are vertical inheritance subclasses of
    AuthorizationDocument.

    At least I'm guessing this was the relationship that caused the
    failure -- unchecking the locking on the two relationships didn't
    solve the problem for me, but maybe I missed something.

    This archive was generated by hypermail 2.0.0 : Wed Sep 13 2006 - 16:09:53 EDT