• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Relation oddity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Relation oddity


  • Subject: Re: Relation oddity
  • From: Wolfram Stebel <email@hidden>
  • Date: Mon, 26 Jun 2006 08:39:53 +0200
  • Thread-topic: Relation oddity

Am 24.06.2006 19:41 Uhr schrieb "Ken Anderson" unter <email@hidden>:

Hi Ken,
thanks for this valuable tip.
> Wolfram,
>
> Do you have an inverse relationship from division to event?  My guess
> is, the other side of the relationship is trumping the relationship
> from event to division.
Yes, I had a big problem a while ago NOT having some reverse relations, so i
always have reverse relations. It is absolutely unclear in which case they
are necessary... (or optional, or recommended, or superfluous...)

>
> What Chuck recommends is absolutely right (IMHO).  The one issue of
> using the list box is, it only does a set to the object, not an
> 'addObjectToBothSidesOfRelationshipWithKey'.  So, when you were
> originally using the set both times (in the factory and with the list
> box), it never set the inverse relationship, so it always worked.
Yes

>
> When I have situations like this, I usually implement a method on the
> component to do addObject...  So in the component, I would have:
>
> public Division division() {
> return theEvent.division();
> }
>
> public void setDivision() {
> theEvent.addObjectToBothSidesOfRelationshipWithKey
> (selectedDivisionFromListbox, "division");
> }
>
> Then, instead of the selection attribute being "theEvent.division",
> it would just be "division".
This seems to be a reasonable reason. I should have found this myself by
creating setters and overrides for addObject...
But i think it is both error prone, either forgetting to write the component
method, or using the set-Method instead of addObj... in the factory method.
One thing helps: always be aware of this pitfall.

> Of course, this code is all written by hand and not tested - but sans
> syntax errors, it should work OK.
>
> I often consider writing a WOPopUpButton that does this (like with an
> extra attribute to say how to set the value), but I've never gotten
> to it.  This is also extremely useful when a related object iterates
> its relationships during a validation step - since you can be sure
> all the relationships are right...
>
> Ken
Appreciate your help

Wolfram
>
>
> On Jun 24, 2006, at 6:19 AM, Wolfram Stebel wrote:
>
>> Hi list,
>>
>> i have a huge data modell and allways use factory methods to create
>> and init
>> EO's. I'm using the defaultEditingContext.
>>
>> In some of the factory methods i assign a Division "d" to a (n:1)
>> relation
>> by the setter (Division is a derived class in a vertical
>> inheritance). "d"
>> is taken from person.defaultDivision, a parameter to the factory
>> method.
>>
>>     theEvent.setDivision ( d );
>>
>> When i edit theEvent in a page, I'm able to set theEvent to another
>> divisione from a popup listbox. The Listbox is bound to a list from a
>> session EO, i.e. client.divisions. The data is saved correctly to the
>> database.
>>
>> When i change the factory method to use
>>
>>     theEvent.addObjectToBothSidesOfRelationshipWithKey ( d,
>> "division" );
>>
>> and continue doing the same (change the division via popup
>> listbox), on the
>> first save the wrong division is saved. I can see that the wrong fk is
>> written.
>> Tracing the values of the division in the save cycle shows the
>> correct value
>> before **and** after the saveChanges.
>> When i open theEvent again and change the list value and save
>> again, the fk
>> is saved to the correct value.
>>
>>
>> Anybody seen this?
>> I was told to use addObjectToBothSidesOfRelationshipWithKey
>> liberally (Hi
>> Chuck :-), Page 38 ).


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Re: Relation oddity (From: Ken Anderson <email@hidden>)

  • Prev by Date: jMechanic & eclipse
  • Next by Date: https connection
  • Previous by thread: Re: Relation oddity
  • Next by thread: Re: Relation oddity
  • Index(es):
    • Date
    • Thread