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 <andru..bjectstyle.org>
> 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
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Tue Dec 11 2007 - 17:26:27 EST