Argh. I found it. Another developer had added a call to
invalidateObjects() deep in the bowels of a getter method. Sorry to have
suspected Cayenne's integrity! In my defense, the symptoms were quite
misleading. The object appeared in the modifiedObjects list and showed the
modified values, even though it got refetched before the commit to the
database. The final clue was seeing the refetch SQL in the log. Oh well...
Along the way I added a couple of little debugging improvements to
EntityResolver.java. Maybe they'll be useful to someone else. I modified
applyDBLayerDefaults():
for (int i = 0; i < relationships.length; i++) {
DbRelationship relationship = (DbRelationship)
relationships[i];
if (relationship.getReverseRelationship() == null) {
DbRelationship reverse =
relationship.createReverseRelationship();
Entity targetEntity = reverse.getSourceEntity();
String name =
makeUniqueRelationshipName(targetEntity);
reverse.setName(name);
reverse.setRuntime(true);
targetEntity.addRelationship(reverse);
List<DbJoin> joins = reverse.getJoins();
if (joins.size() == 1) {
DbJoin join = joins.get(0);
logger.info("added DbRelationship " +
targetEntity.getName() + "." + name
+ " -> "
+ reverse.getTargetEntityName()
+ "; attributes " + join.getSourceName()
+ " -> " + join.getTargetName());
}
else {
logger.info("added DbRelationship " +
targetEntity.getName() + "." + name
+ " -> "
+ reverse.getTargetEntityName()
+ ", joins: " + joins);
}
}
}
Before, it gave a somewhat unhelpful list of the auto-added runtime
relationships at start-up. Now it gives more detail, e.g.:
added DbRelationship NIC.runtimeRelationship0 -> NIC; attributes NIC_ID
-> NIC_ID_SELL
A similar mod in applyObjectLayerDefaults() gives more detail there:
added ObjRelationship Employee.runtimeRelationship42 -> Task;
db-path=taskAssignedToReverse
Now when i'm trying to understand a reference to runtimeRelationship42, I
can refer to the start of the log to see the entities and attributes.
On Fri, Oct 30, 2009 at 5:48 PM, Bryan Lewis <jbryanlewi..mail.com> wrote:
> A weird one here... I'm looking for advice on how to debug it. Using
> Cayenne 3.0M6 on Oracle 8 (but for once I don't think Oracle is the
> culprit).
>
> One operation in our app commits a moderately large set of changes. 26 new
> or modified objects. ONE of the modified objects doesn't get any SQL
> generated and doesn't get written to the database. I've never seen this
> before.
>
> I skimmed through the outstanding Jira list. The discussion of CAY-1008
> says, "Cayenne will not maintain the object graph consistency if there are
> multiple relationships between 2 entities, spanning the same set of joins."
> Could this explain the symptom? If so...
>
> Should I verify that our model has no redundant relationships? Are there
> any helpful tools for this, other than manually sifting through the
> DataMap? (It's 11,000 lines long.)
>
> Our model has a lot of reverse relationships that we don't use, left over
> from Cayenne 2. What's the design guideline now? Should we delete all such
> unneeded DbRelationships? Or should we keep them and add matching
> ObjRelationships for all of them? That is, would it be better to let
> Cayenne add runtimeRelationships or to avoid runtimeRelationships?
>
> I suppose I could step through the Cayenne's traversal of the object graph
> in the debugger, if nobody has any tips.
>
> Thanks,
> Bryan Lewis
>
>
>
>
>
This archive was generated by hypermail 2.0.0 : Sat Oct 31 2009 - 18:14:09 EDT