Chuck, > On 29 Aug 2018, at 7:14 PM, Chuck Hill <ch...@gevityinc.com> wrote: > I am not sure that I am following this correctly. The rule is that no Shared > EO should have a relationship to anything that is not also a Shared EO.
The opposite direction (from normal EC to SEC) should be all right though, should it not? > That includes the tables not materialized into an EO. I do not follow here. My shared entity S had no relationship to non-shared ones at all. Not even an empty one; none altogether. My non-shared entity A has a to-many relationship “aaa” to a non-shared B; B has a to-one relationship “bbb” to shared S (no inverse here). B is the M:N table, i.e., it contains just the A's and S's PKs. When non-shared A contained a flattened relationship “ddd” defined as “aaa.bbb”, EOF kept trying to load A into SEC (which naturally failed). I've removed the flattened “ddd” from the model (no other change there), and implemented its behaviour manually (in A just getting “aaa” programmatically, and then for all its objects collecting their “bbb”'s), and the problem disappeared; A has been no more loaded to SEC. Of course, it might have been caused by something else, which is just loosely related to the change — a log in the code for all I know; the Schrödinger EOF behaviour did bit me once or twice already :) it does seem very weird to me that the flattened thing should be the culprit; that's why I am asking whether such kind of behaviour is to be expected, or whether I should try to hunt for the culprit elsewhere. Thanks and all the best, OC > > From: Webobjects-dev > <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com > <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on > behalf of "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>> > Date: Wednesday, August 29, 2018 at 8:28 AM > To: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com > <mailto:webobjects-dev@lists.apple.com>> > Subject: Flattened one-side M:N fails wildly with SharedEC > > Hi there, > > just have bumped into another weird (at least to me) behaviour. > > In my model, there used to be a very standard M:N relationship, which > exploits an “invisible” intermediate table, flattened “direct” relationships > ad both sides. > > One of the sides lately went to the sharedEC; thus I made sure to delete this > side's flattened relationship. The other side and the intermediate table both > stay outside of the sharedEC, so I thought that is all right. > > It failed miserably with “The shared context recently initialized the object > <non-shared-one> which is already registered in this context yadda yadda”, > i.e., EOF for some godforsaken reason kept loading the non-shared object (the > one whose relationship remained intanct) into SEC along with the shared one > (whose relationship were removed all right, no traces remained; I have > checked about zillion times). > > Out of desperation, I have just tried to remov the flattened relationship > from the non-shared side, exposing instead the intermediate table, and > replacing the flattened relationship by something like > > === > List availablePrototypes { // this is how the original flattened rel has > been named > def mn=this.db_Prototype_DataBlock // 1:N relationship to the > intermediate table, exposed > mn.collect { > it.valueForKey('prototype') // N:1 relationship from the inmdt > table to the shared object > } > } > === > > and it seems to work all right :-O So, it looks like the culprit was the > existence of the flattened rel with definiton > “db_Prototype_DataBlock.prototype” at the non-shared side. > > Is that the intended behaviour? Seems pretty weird to me, but as always, I > might be overlooking something of importance. Or should that work even with > the flattened relationship, and the problems mean I must have done something > wrong elsewhere? > > Thanks and all the best, > OC
_______________________________________________ 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
