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
>
This archive was generated by hypermail 2.0.0 : Tue Dec 11 2007 - 15:23:17 EST