Re: Suggestion: Don't Fault Relationship On Add

[Andrus Adamchik]

Ok, that much Cayenne does already, so I was surprised to hear that it  
didn't work for you. If you still think Cayenne doesn't handle it  
right, please provide the details and we'll look into it.

Andrus

On Dec 11, 2007, at 11:59 PM, Daniel Abrams wrote:

My biggest concern was tripping the to-many fault, so if it avoids
doing that, great.  I guess avoiding tripping the to-one fault is
nice, but not as serious a problem.  When I referred to being "clever"
I didn't actually mean avoid tripping the fault, I meant that if the
fault was tripped intentionally by the user, between the time the
original relationship was set, but before the change was saved to the
database, you may want to use the tripping of the fault to look for
unsaved changes to objects that are or would be referenced in the
to-many fault at the time of save, and include these to maintain
consistency of the object graph.



On Dec 11, 2007 3:22 PM, Andrus Adamchik <[EMAIL PROTECTED]>  
wrote:
We are doing the "extra clever" thing for to-many, avoiding tripping
the list on add. We don't for to-one. Is that the case you are  
talking
about? (Address ->> State is a bit confusing... wouldn't a State have
many Addresses? It appears to be the other way around in your  
example)

Anyways, I disagree that we should ignore object graph consistency
matters as insignificant. From "confusing the users" perspective this
is even worse than fault tripping (speaking from experience with  
early
releases of Cayenne that had their share of object graph bugs).

But we can probably do the clever thing for to-ones as well... After
all CayenneDataObject is just a map on the inside, so we can store
temporary state in it behind users backs (such as the ObjectId of a
target object). Could be a good improvement, although a pretty
fundamental one that will require extensive testing.

Cheers,
Andrus



On Dec 11, 2007, at 9:06 PM, Daniel Abrams wrote:
Hello,

I'm new to Cayenne but have a strong background with EOF.  I
downloaded Cayenne, and found one behavior that I dislike in EOF is
actually somewhat worse (by default) with Cayenne, so I would like  
to
propose a change to the default behavior.

Imagine a regular one to many relationship Address ->> State.

In EOF, if I create a new Address object and attempt to add a  
state by
calling the "strongly recommended"
addObjectToBothSidesOfRelationshipWithKey, I will trip a fault and
retrieve every single address in the entire state as a result.  In  
EOF
there are a couple ways around this, all of which are less than  
ideal.
I can avoid modeling the inverse relationship, but there are many
circumstances where I want this relationship available.  I can
directly call address.addState(someState) but if the inverse
relationship is not a fault, the object graph will get out of sync
unnecessarily.

In Cayenne, I don't even appear to have this option.  The out of the
box behavior for address.addState(someState) calls the inverse
relationship.  This seems to be a wrapper around a method that
resolves to one relationships, with a boolean flag to resolve  
whether
or not to set the back relationship, but even if I were to override
the default behavior, the result is less than ideal.   This is the
behavior I believe to be "correct" for 99% of the applications I  
have
developed:

1) Look at the inverse relationship, if it is a fault do nothing, if
the user really needed these objects, they would have tripped the
fault.
2) If it is not a fault, do go ahead and add the object to the  
inverse
relationship.

Note: The only argument I can see against this behavior is if the  
user
eventually trips the fault before the object is saved to the  
database.
In practice this is almost never a concern, but if you wanted to be
extra clever, when a fault is actually tripped, you could look at  
the
inverse relationship to determine if there existed an object that
hadn't yet been saved, and add it at that time.

I have often been called in to troubleshoot performance problems in
WebObjects applications, and the described behavior is often a big
culprit (along with excessive fault tripping generally), as well as
being confusing for new users.  I would be curious to hear other
opinions, but my request is to make the out of the box behavior  
match
above description.

Thanks,
Daniel Abrams