Re: Flattened one-side M:N fails wildly with SharedEC

[Chuck Hill]

Hi OC,

No, no magic like that.  At least not that I know of.  Subclassing 
EOEditingContext, EOSharedEditingContext, maybe EODatabaseContext is probably 
your best bet to pursue this.

Chuck

From: "ocs@ocs" 
Date: Wednesday, September 26, 2018 at 8:40 AM
To: Chuck Hill 
Cc: WebObjects-Dev Mailing List 
Subject: Re: Flattened one-side M:N fails wildly with SharedEC

Chuck,


On 19 Sep 2018, at 9:57 PM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:
Uh oh, the dreaded Schrödinger EOF behaviour!  Have you figured anything out?

Alas, nope. The darned “The shared context recently initialized the object ...” 
thing occurs intermittently, and whenever I add extra logs to find the culprit, 
it disappears. To occur again the next day or the next week.

Is there some trick to set up something somewhere so that

(a) until the SEC tries to load a non-shared object, all runs normally, there 
are no extra logs nor big performance delays,
(b) but, as soon as that happens, I get a very detailed log which would not 
only say which object is the culprit, but also the reason why has it been 
loaded into SEC, through which relationship, etc.?

Thanks and all the best,
OC



From: "ocs@ocs" mailto:o...@ocs.cz>>
Date: Wednesday, August 29, 2018 at 12:38 PM
To: Chuck Hill mailto:ch...@gevityinc.com>>
Cc: WebObjects-Dev Mailing List 
mailto:webobjects-dev@lists.apple.com>>
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 mailto:o...@ocs.cz>> wrote:

Chuck,



On 29 Aug 2018, at 7:14 PM, Chuck Hill 
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 
mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>>
 on behalf of "ocs@ocs" mailto:o...@ocs.cz>>
Date: Wednesday, August 29, 2018 at 8:28 AM
To: WebObjects-Dev Mailing List 
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 
 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 repla

Re: Flattened one-side M:N fails wildly with SharedEC

[ocs@ocs]

Chuck,

> On 19 Sep 2018, at 9:57 PM, Chuck Hill  wrote:
> Uh oh, the dreaded Schrödinger EOF behaviour!  Have you figured anything out?

Alas, nope. The darned “The shared context recently initialized the object ...” 
thing occurs intermittently, and whenever I add extra logs to find the culprit, 
it disappears. To occur again the next day or the next week.

Is there some trick to set up something somewhere so that

(a) until the SEC tries to load a non-shared object, all runs normally, there 
are no extra logs nor big performance delays,
(b) but, as soon as that happens, I get a very detailed log which would not 
only say which object is the culprit, but also the reason why has it been 
loaded into SEC, through which relationship, etc.?

Thanks and all the best,
OC

>   
> From: "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Wednesday, August 29, 2018 at 12:38 PM
> To: Chuck Hill mailto:ch...@gevityinc.com>>
> Cc: WebObjects-Dev Mailing List  <mailto:webobjects-dev@lists.apple.com>>
> 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 mailto:o...@ocs.cz>> wrote:
>  
> Chuck, 
> 
> 
> On 29 Aug 2018, at 7:14 PM, Chuck Hill  <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 
>  <mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>> on 
> behalf of "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Wednesday, August 29, 2018 at 8:28 AM
> To: WebObjects-Dev Mailing List  <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 
>  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 hav

Re: Flattened one-side M:N fails wildly with SharedEC

[Chuck Hill]

Uh oh, the dreaded Schrödinger EOF behaviour!  Have you figured anything out?

Chuck

From: "ocs@ocs" 
Date: Wednesday, August 29, 2018 at 12:38 PM
To: Chuck Hill 
Cc: WebObjects-Dev Mailing List 
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 mailto:o...@ocs.cz>> wrote:

Chuck,


On 29 Aug 2018, at 7:14 PM, Chuck Hill 
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 
mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>>
 on behalf of "ocs@ocs" mailto:o...@ocs.cz>>
Date: Wednesday, August 29, 2018 at 8:28 AM
To: WebObjects-Dev Mailing List 
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 
 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<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz

This email sent to o...@ocs.cz

 _

Re: Flattened one-side M:N fails wildly with SharedEC

[Chuck Hill]

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" 
Date: Wednesday, August 29, 2018 at 10:49 AM
To: Chuck Hill 
Cc: WebObjects-Dev Mailing List 
Subject: Re: Flattened one-side M:N fails wildly with SharedEC

Chuck,


On 29 Aug 2018, at 7:14 PM, Chuck Hill 
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 
mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>>
 on behalf of "ocs@ocs" mailto:o...@ocs.cz>>
Date: Wednesday, August 29, 2018 at 8:28 AM
To: WebObjects-Dev Mailing List 
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 
 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

Re: Flattened one-side M:N fails wildly with SharedEC

[ocs@ocs]

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  wrote:
> 
> Chuck,
> 
>> On 29 Aug 2018, at 7:14 PM, Chuck Hill > > 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 
>> > > on 
>> behalf of "ocs@ocs" mailto:o...@ocs.cz>>
>> Date: Wednesday, August 29, 2018 at 8:28 AM
>> To: WebObjects-Dev Mailing List > >
>> 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 
>>  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/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be 

Re: Flattened one-side M:N fails wildly with SharedEC

[ocs@ocs]

Chuck,

> On 29 Aug 2018, at 7:14 PM, Chuck Hill  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 
>  > on 
> behalf of "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Wednesday, August 29, 2018 at 8:28 AM
> To: WebObjects-Dev Mailing List  >
> 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 
>  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

Re: Flattened one-side M:N fails wildly with SharedEC

[Chuck Hill]

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 
 on behalf of 
"ocs@ocs" 
Date: Wednesday, August 29, 2018 at 8:28 AM
To: WebObjects-Dev Mailing List 
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 
 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