And  I would add modeling your business because of the UI is not a good sign, 
even with D2W (except implementing userPresentableDescription)

Philippe
---------------------
http://twitter.com/prabier

Sent from my iPhone

> On 04 Mar 2014, at 19:57, Chuck Hill <ch...@global-village.net> wrote:
> 
> 
> 
> 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 <r...@ganymede.org> wrote:
> 
> On Sun, 02 Mar 2014 16:05:26 +0100
> Jean Pierre Malrieu <jp.malr...@free.fr> 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 <prab...@me.com> 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 
> 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to