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: "ocs@ocs" <email@hidden>
- Date: Wed, 29 Aug 2018 19:49:28 +0200
Chuck,
> On 29 Aug 2018, at 7:14 PM, Chuck Hill <email@hidden> 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=email@hidden
> <mailto:webobjects-dev-bounces+chill=email@hidden>> on
> behalf of "ocs@ocs" <email@hidden <mailto:email@hidden>>
> Date: Wednesday, August 29, 2018 at 8:28 AM
> To: WebObjects-Dev Mailing List <email@hidden
> <mailto: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