Hi OC, Sorry, this got lost (scrolled off the screen) in my in-box.
I am not sure why this is happening, but what you are describing is a bug. Somewhere… Those relationships and the flattened relationship should work as you expect. Chuck From: "ocs@ocs" <o...@ocs.cz> Date: Wednesday, August 29, 2018 at 10:49 AM To: Chuck Hill <ch...@gevityinc.com> Cc: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com> Subject: Re: Flattened one-side M:N fails wildly with SharedEC Chuck, On 29 Aug 2018, at 7:14 PM, Chuck Hill <ch...@gevityinc.com<mailto: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
