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

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Sep 14 2006 - 10:56:30 EDT

  • Next message: Michael Gentry: "Re: Move success stories to the Wiki"

    Mike,

    I don' have time to look into this in depth right away. If you still
    find this an issue, could you create a test case and log it in to Jira?

    Andrus

    On Sep 13, 2006, at 3:59 PM, Mike Kienenberger wrote:

    > 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 : Thu Sep 14 2006 - 11:06:25 EDT