Re: Flattened one-side M:N fails wildly with SharedEC
Re: Flattened one-side M:N fails wildly with SharedEC
- Subject: Re: Flattened one-side M:N fails wildly with SharedEC
- From: Chuck Hill <email@hidden>
- Date: Wed, 29 Aug 2018 17:14:53 +0000
- Thread-topic: Flattened one-side M:N fails wildly with SharedEC
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. That
includes the tables not materialized into an EO.
Chuck
From: Webobjects-dev
<webobjects-dev-bounces+chill=email@hidden> on behalf of
"ocs@ocs" <email@hidden>
Date: Wednesday, August 29, 2018 at 8:28 AM
To: WebObjects-Dev Mailing List <email@hidden>
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden