Re: Flattened to-one relationship problems
Re: Flattened to-one relationship problems
- Subject: Re: Flattened to-one relationship problems
- From: David Avendasora <email@hidden>
- Date: Tue, 04 Mar 2014 13:17:48 -0500
Yikes!
So, if I’m reading this right, you have a class property of “classe()” and *also* a flattened class property of “lycée()” and you made the (Model) change to make creating the UI (View) more convenient. Is that right?
If so, you are asking for all kinds of trouble.
Have you verified that calling setLycée() also changes the value of classe().lycée() because I’m not entirely sure it always will, especially if you have a UI that shows both. Having multiple paths to the exact same column in the database is very dangerous and completely non-deterministic in the way in which it will fail.
Sometimes it will work as you expect, other times it will simply not use the new value, other times you will get optimistic locking failures (IF you have locking turned on on the FK).
This is guaranteed to happen if you have FKs marked as class properties, but I can see it happening here too. The reason flattening works with many-to-many relationships is that the relationships to the join table are NOT class properties.
Dave
On Mar 3, 2014, at 2:25 PM, Ray Kiddy <email@hidden> wrote:
> On Sun, 02 Mar 2014 16:05:26 +0100
> Jean Pierre Malrieu <email@hidden> wrote:
>
>> Actually I think I solved the problem by using the relationship
>> keypath in the qualifier:
>>
>> if ( cd.toOneRelationshipKeys().contains(sv1)) {
>> EORelationship relation1 = entity.relationshipNamed(sv1);
>> v1Qual= new EOKeyValueQualifier(relation1.relationshipPath(),
>> EOQualifier.QualifierOperatorEqual, record); }
>> NSArray objectsInRow =
>> EOQualifier.filteredArrayWithQualifier(relevantObjects, v1Qual);
>>
>> That seems to work.
>
> So, it seems that you fixed the problem by not accessing the
> relationship via the flattened path. That would work.
>
> Flattening a to-one relationship is possible, though certainly not the
> common use case.
>
> It is likely that you fell afoul of the rule that the inner
> relationships in the chain of the flattened relationships should not be
> class properties. If you took a set of to-one relationships that were
> not class properties, you can flatten them. It would just be strange to
> create the to-one relationships in that manner.
>
> When I have a common path through some set of relationships, I usually
> provide support for that in the class by creating a final static of the
> qualifier, or add methods to get across the set of joins, or both.
>
> - ray
>
>>
>> Le 2 mars 2014 à 14:39, Philippe Rabier <email@hidden> a écrit :
>>
>>> I don’t understand why you try to flatten a to-one relationship.
>>> You can flatten an attribute or a many2many relationship.
>>
>> Instead of calling classe().lycée(), I can just call lycée().
>> It is also useful to me because I I dynamically present the relations
>> to the user for selection in a popup menu. So I need a direct
>> relationship to Lycée.
>>
>>>
>>> Creating a many2many relationship is pretty straightforward: when
>>> you create a relationship between 2 entities, you choose to many on
>>> both sides, give a name to the join entity and check “flatten”.
>>>
>>> Regarding your code, I don’t get you when you say “not work well
>>> with this relationship”. Is it the one to try to flatten? If you
>>> have issues with the relationship, it’s not surprising you don’t
>>> get the expected results, right?
>>>
>>> Why the test "if ( cd.toOneRelationshipKeys().contains(sv1)) "? I
>>> suppose you get an exception before if sv1 is not a valid
>>> relationship key…
>>
>> Because I build different qualifiers if the relationship is a to-many
>> (I didn't show it in the code I sent, because it is not relevant).
>>
>>>
>>> And I’m a bit surprised you still use accented characters (Lycée).
>>> That’s something I would never play with…
>>
>> You are right, but this is D2W app, and I thought it would save me
>> writing a lot of displayNameForProperty rules.
>>
>> Thanks for your reply
>>
>> JPM
>
> _______________________________________________
> 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
—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Nekesto, Inc.
_______________________________________________
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