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 - 16:59:35 EST