On 2014-03-04, 10:17 AM, "David Avendasora" wrote:
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. Almost demanding 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. Actually, I’d guess that it will pretty deterministically fail as there are two copies of the data. Chuck 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 protected]<mailto:[email protected]>> wrote: On Sun, 02 Mar 2014 16:05:26 +0100 Jean Pierre Malrieu <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com This email sent to [email protected]<mailto:[email protected]> ————————————————————————————— 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 protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net This email sent to [email protected]<mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
