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

Flattened one-side M:N fails wildly with SharedEC

[ocs@ocs]

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: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)

[Chuck Hill]

EOF will reconnect if the connection to the database is lost (database 
restarted, network problems, etc.).  See the EOAdaptor.Delegate method

reconnectionDictionaryForAdaptor

NSDictionary 
reconnectionDictionaryForAdaptor(EOAdaptor adaptor)
Creates a new connection dictionary for the adaptor. It is responsible for 
guaranteeing that the new connection dictionary is compatible with any 
EODatabase that is currently using the adaptor. Note that if reconnection 
succeeds, the EODatabase will continue to use its database snapshots as if 
nothing had happened so the new database server should have the same data as 
the original.

I am not sure that will be useful in your case.

Chuck

From: "ocs@ocs" 
Date: Wednesday, August 29, 2018 at 4:54 AM
To: Chuck Hill 
Cc: "webobjects-dev@lists.apple.com" 
Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get 
sharedEC automagically?)

Thanks a lot!

Incidentally, is there somewhere a clean set of rules when might EOF decide to 
re-connect using the model CD?

What I mean is

(a) I set up the CD to contain some settings (e.g., “isolation=read_committed” 
in URL)
(b) I force this to be used through forceConnectionWithModel, overriding the 
URL to “isolation=serializable”
(c) I perform the init work
(d) at end of which I reconnect, again using forceConnectionWithModel, this 
time without an override, so that “read_committed” applies.

Far as my testing goes, this works.

Nevertheless, may I be sure that during (c), EOF would never happen to 
reconnect by itself, using the CD from the model? Should I perhaps instead of 
the above, to keep at the safe side, do uglier, but perhaps more robust

(a) set up the CD to contain temporary settings (“isolation=serializable” in 
URL)
(b) either use forceConnectionWithModel without an override, or just let EOF to 
connect automatically;
(c) do the init work
(d) at end of which change the CD in all models to “isolation=read_committed”, 
and reconnect using forceConnectionWithModel without an override

? Thanks!
OC


On 27 Aug 2018, at 5:48 AM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:

Finally, an easy question!

Compatible just means that 
modelA.connectionDictionary().equals(modelB.connectionDictionary())

Chuck

From: "ocs@ocs" mailto:o...@ocs.cz>>
Date: Thursday, August 23, 2018 at 7:03 PM
To: Chuck Hill mailto:ch...@gevityinc.com>>
Cc: "webobjects-dev@lists.apple.com" 
mailto:webobjects-dev@lists.apple.com>>
Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get 
sharedEC automagically?)

Chuck,

I guess I have solved the mystery :) Looks like all what's needed is

- to set up freely the OSCPool with any number of coordinators
- at the init time, to use "isolation=serializable/locking=pessimistic" in my 
models
- and switch off the SEC (by setting it to null in my ERXEC)
- when all the init work is done, I simply call

EODatabaseContext.forceConnectionWithModel(model,[URL:"jdbc:FrontBase://$dbhost/$dbname/user=$user/isolation=read_committed/locking=optimistic"],ec)

and that's that, it seems it works all right, for subsequently all 
(session-based) ECs seem to work properly with the (OSC-based) SEC, and the 
connexion indeed is read-committed/optimistic, as need be.

There's just one small thing I am not sure of: forceConnectionWithModel 
re-connects “all compatible models in the model group” too. Alas the 
documentation does not say what a “compatible” model is — what does that mean? 
How does the EOF determine which models are compatible?

Thanks and all the best,
OC



On 22 Aug 2018, at 2:06 PM, ocs@ocs mailto:o...@ocs.cz>> wrote:

Chuck,

hmmm... coudn't I somehow switch off temporarily the OSCPool, so that the 
initialisation code happens precisely as if there was no pool at all, and only 
then, when done, the pool starts behaving as normally? Actually I could benefit 
— if it is possible — from that, not only due to the SEC, but for other reasons 
as well (it would help if I could run the initialisation code against the DB in 
the “isolation=serializable/locking=pessimistic” mode, switching to 
“isolation=read_committed/locking=optimistic” for the normal processing).

The init code just reads some objects from the db (including 
INFORMATION_SCHEMA, which is the reason for the DB mode), checks them, 
potentially updates them, and that's that — if at this moment the application 
quits and immediately runs again without the init code, it would work just as 
well. But for the objects in the shared EC, there's no EO which the init code 
would create/fetch and a later session-based code would use anyhow.

I might switch off the SEC for the initialisation completely: I would run the 
init code using an EC with its SEC explicitly set to null, then somehow trash 
the init EO stack completely and start afresh with a new one (or ones with 
OSCPool) and normal session-based processing.

Can this, i.e.,

- to begin without OSCPool and connecting to DB 

Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)

[ocs@ocs]

Thanks a lot!

Incidentally, is there somewhere a clean set of rules when might EOF decide to 
re-connect using the model CD?

What I mean is

(a) I set up the CD to contain some settings (e.g., “isolation=read_committed” 
in URL)
(b) I force this to be used through forceConnectionWithModel, overriding the 
URL to “isolation=serializable”
(c) I perform the init work
(d) at end of which I reconnect, again using forceConnectionWithModel, this 
time without an override, so that “read_committed” applies.

Far as my testing goes, this works.

Nevertheless, may I be sure that during (c), EOF would never happen to 
reconnect by itself, using the CD from the model? Should I perhaps instead of 
the above, to keep at the safe side, do uglier, but perhaps more robust

(a) set up the CD to contain temporary settings (“isolation=serializable” in 
URL)
(b) either use forceConnectionWithModel without an override, or just let EOF to 
connect automatically;
(c) do the init work
(d) at end of which change the CD in all models to “isolation=read_committed”, 
and reconnect using forceConnectionWithModel without an override

? Thanks!
OC

> On 27 Aug 2018, at 5:48 AM, Chuck Hill  wrote:
> 
> Finally, an easy question!
>  
> Compatible just means that 
> modelA.connectionDictionary().equals(modelB.connectionDictionary())
>  
> Chuck
>  
> From: "ocs@ocs" mailto:o...@ocs.cz>>
> Date: Thursday, August 23, 2018 at 7:03 PM
> To: Chuck Hill mailto:ch...@gevityinc.com>>
> Cc: "webobjects-dev@lists.apple.com " 
> mailto:webobjects-dev@lists.apple.com>>
> Subject: Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get 
> sharedEC automagically?)
>  
> Chuck, 
>  
> I guess I have solved the mystery :) Looks like all what's needed is
>  
> - to set up freely the OSCPool with any number of coordinators
> - at the init time, to use "isolation=serializable/locking=pessimistic" in my 
> models
> - and switch off the SEC (by setting it to null in my ERXEC)
> - when all the init work is done, I simply call
>  
> EODatabaseContext.forceConnectionWithModel(model,[URL:"jdbc:FrontBase://$dbhost/$dbname/user=$user/isolation=read_committed/locking=optimistic
>  
> "],ec)
>  
> and that's that, it seems it works all right, for subsequently all 
> (session-based) ECs seem to work properly with the (OSC-based) SEC, and the 
> connexion indeed is read-committed/optimistic, as need be.
>  
> There's just one small thing I am not sure of: forceConnectionWithModel 
> re-connects “all compatible models in the model group” too. Alas the 
> documentation does not say what a “compatible” model is — what does that 
> mean? How does the EOF determine which models are compatible?
>  
> Thanks and all the best,
> OC
> 
> 
> On 22 Aug 2018, at 2:06 PM, ocs@ocs mailto:o...@ocs.cz>> wrote:
>  
> Chuck, 
>  
> hmmm... coudn't I somehow switch off temporarily the OSCPool, so that the 
> initialisation code happens precisely as if there was no pool at all, and 
> only then, when done, the pool starts behaving as normally? Actually I could 
> benefit — if it is possible — from that, not only due to the SEC, but for 
> other reasons as well (it would help if I could run the initialisation code 
> against the DB in the “isolation=serializable/locking=pessimistic” mode, 
> switching to “isolation=read_committed/locking=optimistic” for the normal 
> processing).
>  
> The init code just reads some objects from the db (including 
> INFORMATION_SCHEMA, which is the reason for the DB mode), checks them, 
> potentially updates them, and that's that — if at this moment the application 
> quits and immediately runs again without the init code, it would work just as 
> well. But for the objects in the shared EC, there's no EO which the init code 
> would create/fetch and a later session-based code would use anyhow.
>  
> I might switch off the SEC for the initialisation completely: I would run the 
> init code using an EC with its SEC explicitly set to null, then somehow trash 
> the init EO stack completely and start afresh with a new one (or ones with 
> OSCPool) and normal session-based processing.
>  
> Can this, i.e.,
>  
> - to begin without OSCPool and connecting to DB in the 
> “isolation=serializable/locking=pessimistic” mode;
> - do some stuff (without SEC), save changes;
> - completely trash the EO stack;
> - create a new one with OSCPool connecting to DB in the 
> “isolation=read_committed/locking=optimistic” mode with SEC, and run happily 
> ever after
>  
> be done in some cleaner way than, well, restarting the application — which 
> with some trickery exploiting Auto Recover in JavaMonitor might even prove 
> possible, but would be super-ugly and I would rather do without?
>  
> Thanks,
> OC
> 
> 
> On 22 Aug 2018, at 5:11 AM, Chuck Hill  > wrote:
>  
> That is a good question.  I’ve not used the combination.   There must be some 
> code that uses the default instead of getting the SEC from