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, 19 Sep 2018 19:57:24 +0000
- Thread-topic: Flattened one-side M:N fails wildly with SharedEC
Uh oh, the dreaded Schrödinger EOF behaviour! Have you figured anything out?
Chuck
From: "ocs@ocs" <email@hidden>
Date: Wednesday, August 29, 2018 at 12:38 PM
To: Chuck Hill <email@hidden>
Cc: WebObjects-Dev Mailing List <email@hidden>
Subject: Re: Flattened one-side M:N fails wildly with SharedEC
Darn...
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
... I should have not written this part!
I have seen the blasted “The shared context recently initialized the object
...” thing again.
Added log to pursue it. It did not happen.
Removed the log. It still did not happen.
Curiouser and curiouser...
Thanks and all the best,
OC
On 29 Aug 2018, at 7:49 PM, ocs@ocs <email@hidden<mailto:email@hidden>> wrote:
Chuck,
On 29 Aug 2018, at 7:14 PM, Chuck Hill
<email@hidden<mailto: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<mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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