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 <andru..bjectstyle.org> 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.
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 14 2006 - 13:19:54 EDT