It's an issue, and the above code change fixes it for me.
The question is whether there's ever any reason for a primary key
attribute to have a relationship Transformer. And I think the answer
is no.
Making this message into a jira issue is already on my list as a todo item.
On 9/14/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
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.
>
