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 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
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()
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.
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())) {
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.
