Re: Relation oddity
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