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... Thoughts?
