cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Optimistic locking fails if primary key is used in an ObjRelationship -- CAY-595
Date Wed, 13 Sep 2006 19:59:14 GMT
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.

Mime
View raw message