cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Exposed FK and redundant mappings
Date Wed, 19 Oct 2011 07:02:50 GMT
Just coming of a few months (!) of low intensity debugging of a single problem that looked
as if Cayenne resets a non-null to-one relationship to null. The FK would be not null in the
DB, but all instances of a given object across all DataContexts in a given app would return
null for that one relationship. Turned out this wasn't an obscure race condition, but rather
the following scenario:

1. Assume Artist and Painting with painting having to one relationship called "artist", but
also an ObjAttribute called "artistId"
2. For an existing Artist you may create a new painting, call "setArtist", but don't set the
"artistId" attribute explicitly. 
3. Commit - that creates a valid record with non-null PAINTING.ARTIST_ID in the db, but the
object snapshot stored in DataRowStore suddenly has NULL for "ARTIST_ID" key.
4. From here all DataContexts that fault this painting from the shared cache will have NULL
"artist" relationship, even though it is not null in the DB.

The actual behavior during (3 - commit) I think is less deterministic and depends on the relative
order of traversal of entity properties in the ClassDescriptor. So theoretically there may
have been a reverse situation when NULL was saved to the DB, but not-null value remained in
the snapshot. In any event it is extremely confusing.

If we take a broader look at this problem, it is a case of redundant mapping (something in
the DB layer is mapped multiple times in the object layer). There can be other cases with
yet unknown sets of problems (e.g. multiple ObjRelationships over the same DbRelationship;
flattened relationships, with a matching set of 1-step relationships; etc). 

We only have a single case where redundant mapping is handled correctly and consistently -
exposed PK (meaningful or not) . Even if the exposed PK is generated by Cayenne, we have a
mechanism to update object property. So this is a case when we do it right, and don't compromise
on user choices of mapping scenarios.

In case of exposed FK we have 2 options - (1) just add a Modeler validation to discourage
this type of mapping (quick and easy) and (2) actually analyze the above and other possible
scenarios when we need to synchronize relationship and attribute and write code to do that.
#2 can be done as a post-commit pass over the objects to sync redundant mappings... Just not
clear which one of the redundant mappings should be used to sync the others...

View raw message