You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Bryan Lewis <jb...@gmail.com> on 2009/10/30 22:48:33 UTC

failure to commit part of the changes

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

Re: failure to commit part of the changes

Posted by Bryan Lewis <jb...@gmail.com>.
Resending my last post.  The list rejected it as spam, probably because I
sent two posts in the same minute.


Now that I've had a day to cogitate on it and to re-read CAY-1008, the issue
> I addressed in my "model validation" code wasn't the important one.  Having
> redundant DbRelationships isn't risky; it's ony a cleanliness issue.  Having
> multiple ObjRelationships sharing the same DbRelationship is the case in the
> Jira.  I wrote a little more code today in EntityResolver to check for that:
>
>     private void validateObjLayer()
>     {
>         for (DataMap map : getDataMaps()) {
>             for (ObjEntity entity : map.getObjEntities()) {
>                 ArrayList dbpaths = new ArrayList<String>();
>                 for (ObjRelationship rel : entity.getRelationships()) {
>                     String dbpath = rel.getDbRelationshipPath();
>                     if (dbpaths.contains(dbpath)) {
>                         // Redundant ObjRelationships can lead to
> misbehavior; see CAY-1008.
>                         logger.warn("!! Found redundant ObjRelationship "
>                                 + entity.getName() + "."
>                                 + rel.getName()
>                                 + " sharing DbRel " + dbpath);
>                     }
>                     dbpaths.add(dbpath);
>                 }
>             }
>         }
>     }
>
> So you might see in the log at start-up:
>
>     !! Found redundant ObjRelationship Company.industry2 sharing DbRel
> industry
>
>
>

Re: failure to commit part of the changes

Posted by Bryan Lewis <jb...@gmail.com>.
I don't think so.  One of my patches merely prints more details about the
auto-supplied runtimeRelationships at startup.  The Jira is talking about
formatting the QueryLogging throughout the session.  Sort of related, I
guess, in that both are trying to improve the readability of the log.


On Mon, Nov 2, 2009 at 10:27 AM, Michael Gentry <mg...@masslight.net>wrote:

> Hi Bryan,
>
> Is this similar to what Evgeny was talking about on the developer list
> for CAY-1300?
>
> http://issues.apache.org/jira/browse/CAY-1300
>
>
> mrg
>

Re: failure to commit part of the changes

Posted by Michael Gentry <mg...@masslight.net>.
Hi Bryan,

Is this similar to what Evgeny was talking about on the developer list
for CAY-1300?

http://issues.apache.org/jira/browse/CAY-1300


mrg

Re: failure to commit part of the changes

Posted by Bryan Lewis <jb...@gmail.com>.
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 <jb...@gmail.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
>
>
>
>
>

Re: failure to commit part of the changes

Posted by lenka <li...@gmail.com>.
LAURIT - Lenka Laurincikova
Druzstevna 26/2
02601 Bziny, Slovakia
Mob: +421 903 506 194
e-mail: lenka.laurincikova@laurit.sk
skype: lienok81
-----------
Myslite na prírodu... Skutočne potrebujete vytlačiť tento e-mail?
Please consider your environmental responsibility before printing this
e-mail.


-----Pôvodná správa-----
Od: Bryan Lewis <jb...@gmail.com>
Reply-to: user@cayenne.apache.org
Komu: user@cayenne.apache.org
Predmet: failure to commit part of the changes
Dátum: Fri, 30 Oct 2009 17:48:33 -0400


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