Suggestion: Don't Fault Relationship On Add

From: Daniel Abrams (dabram..mail.com)
Date: Tue Dec 11 2007 - 14:06:07 EST

  • Next message: Peter Karich: "Re: Suggestion: Don't Fault Relationship On Add"

    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 - 14:06:39 EST