August 2018 - Webobjects-dev

Re: Trim values in displaygroup
by Michael Kondratov 30 Aug '18

30 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= aspireauctions.com; h=references:message-id :content-transfer-encoding:date:date:in-reply-to:x-mailer:from :from:subject:subject:mime-version:content-type:content-type :received:received; s=mail; t=1535659777; x=1538251778; bh=yRzud tzFSSqt2cmpJVEp46bWLu2TlYjBDb0VG9jkJIc=; b=dbqkPnkicD2Y980HotO6i w3smP6RqTtJD+xBymBRL7+i2gLG20DOy6vU9ZNjm274ogfzAQ/oPv/RuOYvp7NI6 uNF0ZsYxgG51kmKqNlAhDfiDYkQzg06nVEzyEZc/AeCC6dNMzbfNX2nn9m5J+yMU DlCtNpme3PGyoLUA2h84Zc= That’s brilliant!!! Thank you ! Michael Sent from my iPhone > On Aug 30, 2018, at 3:17 PM, Lockhart, Dawn <dlockhart(a)k12.com> wrote: > > Add this to your properties file: > > er.extensions.ERXGenericRecord.shouldTrimSpaces=true > > >> >> >> >> Message: 2 >> Date: Thu, 30 Aug 2018 14:21:24 -0400 >> From: Michael Kondratov <michael(a)aspireauctions.com> >> To: webobjects-dev(a)lists.apple.com >> Subject: Trim values in displaygroup >> Message-ID: <BC2C838C-ED8A-4EB4-A88B-220A8AC0813F(a)aspireauctions.com> >> Content-Type: text/plain; CHARSET=US-ASCII >> >> Hello! >> Is there an easy way to trim string values in WoTextfield before it >> gets submitted to display group queryMatch? >> >> For example we need to remove trailing spaces from last name search. >> >> Michael >> >> Sent from my iPhone >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Webobjects-dev mailing list >> Webobjects-dev(a)lists.apple.com >> https://lists.apple.com/mailman/listinfo/webobjects-dev >> >> >> ------------------------------ >> >> End of Webobjects-dev Digest, Vol 15, Issue 105 >> *********************************************** > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauct… > > This email sent to michael(a)aspireauctions.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Trim values in displaygroup
by Lockhart, Dawn 30 Aug '18

30 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Thread-index: AQHUQJYnIZloNHc3vkWKETBgIfMhAQ== Thread-topic: Trim values in displaygroup User-agent: Microsoft-MacOutlook/14.7.7.170905 Add this to your properties file: er.extensions.ERXGenericRecord.shouldTrimSpaces=true > > > >Message: 2 >Date: Thu, 30 Aug 2018 14:21:24 -0400 >From: Michael Kondratov <michael(a)aspireauctions.com> >To: webobjects-dev(a)lists.apple.com >Subject: Trim values in displaygroup >Message-ID: <BC2C838C-ED8A-4EB4-A88B-220A8AC0813F(a)aspireauctions.com> >Content-Type: text/plain; CHARSET=US-ASCII > >Hello! > Is there an easy way to trim string values in WoTextfield before it >gets submitted to display group queryMatch? > >For example we need to remove trailing spaces from last name search. > >Michael > >Sent from my iPhone > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Webobjects-dev mailing list >Webobjects-dev(a)lists.apple.com >https://lists.apple.com/mailman/listinfo/webobjects-dev > > >------------------------------ > >End of Webobjects-dev Digest, Vol 15, Issue 105 >*********************************************** _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Trim values in displaygroup
by Michael Kondratov 30 Aug '18

30 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= aspireauctions.com; h=x-mailer:message-id:subject:subject:date :date:mime-version:content-transfer-encoding:content-type :content-type:from:from:received:received; s=mail; t=1535653286; x=1538245287; bh=FVOr9c9GEuD15PON53zOCiyCEDKYmhxXVLn/+Owos3s=; b= F73CH/XMEOcBOnl1B8YZjh8rYbF3RtzjnnmjnWUQVJgRn2l4ANsECm+JJQHd6RLD G1P1OVszUcBgVBQjg4hozwPJ49RHblBsnC2YpRyZKrURn9Z3DDziM/cQ91k3nEWJ +eaZDn+iCOdStnLDGVi5jXbIIX266Kj/kol6eWkrtxE= Hello! Is there an easy way to trim string values in WoTextfield before it gets submitted to display group queryMatch? For example we need to remove trailing spaces from last name search. Michael Sent from my iPhone _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Flattened one-side M:N fails wildly with SharedEC
by ocs＠ocs 29 Aug '18

29 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com 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 <ocs(a)ocs.cz> wrote: > > Chuck, > >> On 29 Aug 2018, at 7:14 PM, Chuck Hill <chill(a)gevityinc.com >> <mailto:chill@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 >> <webobjects-dev-bounces+chill=gevityinc.com(a)lists.apple.com >> <mailto:webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com>> on >> behalf of "ocs@ocs" <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> >> Date: Wednesday, August 29, 2018 at 8:28 AM >> To: WebObjects-Dev Mailing List <webobjects-dev(a)lists.apple.com >> <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 >> <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 (Webobjects-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz > > This email sent to ocs(a)ocs.cz _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Flattened one-side M:N fails wildly with SharedEC
by ocs＠ocs 29 Aug '18

29 Aug '18

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

1 0

Re: Flattened one-side M:N fails wildly with SharedEC
by Chuck Hill 29 Aug '18

29 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gevityinc.onmicrosoft.com; s=selector1-gevityinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BDDrqt8BNZygx1m72s440u2MlX/x41MYYeg9FfUQEJ0=; b=hC5Qq0RUlstvlUMipk95ogI0zu1VHl5U6PRZsxKwSMiK6kVSL8I66eXciyCaMDjSEVUO6zW8DXHGuvUNgPmQRZLtjzNILPmpQ2jGdMAna8/eHQAj8WD4S9r5ixoRWItz8B8n5iUgGZR2DDPALvjBFQOsQRw6V4c78AoR/EM3Wvc= Spamdiagnosticmetadata: NSPM Spamdiagnosticoutput: 1:99 Thread-index: AQHUP6z39vUwYN4dv0+f4K4hPBtGeKTWguUA 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=gevityinc.com(a)lists.apple.com> on behalf of "ocs@ocs" <ocs(a)ocs.cz> Date: Wednesday, August 29, 2018 at 8:28 AM To: WebObjects-Dev Mailing List <webobjects-dev(a)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 <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 (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Flattened one-side M:N fails wildly with SharedEC
by ocs＠ocs 29 Aug '18

29 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com 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 (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
by Chuck Hill 29 Aug '18

29 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gevityinc.onmicrosoft.com; s=selector1-gevityinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BUgIEAVZo7qDk0F8f5rZNsWWybkVmdlbLDGv2PdEtmw=; b=dLpexuYj7/KmdhYNSI5i/0XRP+HG88GT0RlXzcCYsrFFebsD4Ppm5tNW//kV8KNzMq8UZNQflz+Cn2IlB+xphqbvZEvLUiOr0lWaUcbDXvM30t4dkWKyXQGQAsd6zEswKz6xcHJTxlWdAGnsoTXey0p7n9d4KhhpYukeljqQx/8= Spamdiagnosticmetadata: NSPM Spamdiagnosticoutput: 1:99 Thread-index: AQHUOhCcCiGDuXdauUezdrE/XVYZIaTOKT+AgARfAgCABCHIgP//tLGA Thread-topic: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?) EOF will reconnect if the connection to the database is lost (database restarted, network problems, etc.). See the EOAdaptor.Delegate method reconnectionDictionaryForAdaptor NSDictionary<java.lang.String,java.lang.Object> 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" <ocs(a)ocs.cz> Date: Wednesday, August 29, 2018 at 4:54 AM To: Chuck Hill <chill(a)gevityinc.com> Cc: "webobjects-dev(a)lists.apple.com" <webobjects-dev(a)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 <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: Finally, an easy question! Compatible just means that modelA.connectionDictionary().equals(modelB.connectionDictionary()) Chuck From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Thursday, August 23, 2018 at 7:03 PM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)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<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 <ocs(a)ocs.cz<mailto:ocs@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 <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> 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 the EOEditingContext. There is a lot of code in Wonder (and some in WO) that assumes the defaultWhatever is the only one that will ever exist. You would have to step into the code to see where this is happening, or enable the logging of stack traces of fetches. It should be a simple fix once you find the spot. Chuck From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 1:02 PM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? Indeed! If I switch off the OSCPool, it starts to work properly. Thanks just again! Nevertheless, I still must be missing something of grave importance, for with OCSPool (I use ), I would presume the SEC for the pool being currently used by the ERXEC would load the shared objects? It does not: the global one does automatically load the shared objects, but the SEC-based one of ERXEC remains empty. Note: the code in question does not run in a session context; it is performed at launch, before the first session is created. Might that be important perhaps? All the best, OC On 21 Aug 2018, at 9:42 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: Are you using the ERXObjectStoreCoordinatorPool? It keeps one SEC per pool, not one shared globally. EOSharedEditingContext.defaultSharedEditingContext() is the global one. Chuck From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 12:23 PM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? P.S. It seems ERX completely ignores the default shared EC, using its own one. If I try e.g., this: === println "The default sharedEC is ${EOSharedEditingContext.defaultSharedEditingContext()}" 6.times { def e=ERXEC.newEditingContext() println "EC $e gets sec $e.sharedEditingContext" } println "The default sharedEC still is ${EOSharedEditingContext.defaultSharedEditingContext()}" === it looks like this: === The default sharedEC is com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 2005 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - initializing Pool... 2008 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - initializing Pool finished EC er.extensions.eof.ERXEC@40e32762 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@7d78f3d5 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@f5b6e78 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@71926a36 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@48976e6d gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@7f6874f2 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a The default sharedEC still is com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 === Thanks and all the best, OC On 21 Aug 2018, at 9:07 PM, ocs@ocs <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> wrote: Chuck, sorry, I did not describe the problem clearly enough... On 21 Aug 2018, at 8:39 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: Once an EC has objects in it, its shared EC won’t get changed if a new default is set. The notification is ignored. Quite, but that's not the problem. With EOEditingContext, it works like this: (i) ec created, has no sharedEC (ec.sharedEditingContext==null) (ii) (due to something which creates a DBContext, I believe) the default sharedEC is initialized; it loads the shared objects, and sends the notification (iii) ec observes the notification, and sets the default sharedEC as its own sharedEC (for it is still empty) (iv) now, ec fetches the objects — automatically giving shared ones from its sharedEC, which does contain them With ERXEC (and ERXEC.useSharedEditingContext=true), there's an important difference: (i) erxec created, immediately gets a sharedEC (ec.sharedEditingContext!=null). This sharedEC differs from the default shared EC (ii) (due to something which creates a DBContext, I believe) the default sharedEC is initialized; it loads the shared objects, and sends the notification (iii) erxec (although still empty) does nothing, it already has a sharedEC, different from the default one (iv) now, erxec fetches the objects — would automatically give shared ones from its sharedEC, which, alas, contains nothing (the default one does). Thanks and all the best, OC From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 11:21 AM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? Chuck, On 21 Aug 2018, at 7:50 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: See er.extensions.ERXEC.useSharedEditingContext at https://wiki.wocommunity.org/display/documentation/Explanation+of+the+defau… Thanks a lot! (Why on earth don't they mention this on the ERXEC documentation page? Oh, never mind.) Did that fix it? Well, sort of. It gets curiouser and curiouser — in other words, I must be doing something far wrong. When I set the “ERXEC.useSharedEditingContext” property to true, then - the newly created ERXEC gets a shared editing context immediately upon creation, not later upon receiving DefaultSharedEditingContextWasInitializedNotification; - and it is a different shared EC instance, not EOSharedEditingContext.defaultSharedEditingContext() - but it is EOSharedEditingContext.defaultSharedEditingContext() who reads in automatically all the shared EOs - and therefore, when fetching EOs through the ERXEC, I am still getting non-shared ones in the ERXEC (for its own sharedEC is empty, and thus EOSharedEditingContext.defaultSharedEditingContext is ignored). Can you make any sense of that? Thanks again a very big lot, OC On 2018-08-21, 9:43 AM, "Webobjects-dev on behalf of ocs@ocs" <webobjects-dev-bounces+chill=gevityinc.com(a)lists.apple.com<mailto:webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com> on behalf of ocs(a)ocs.cz<mailto:ocs@ocs.cz>> wrote: Hi there, the EOEditing context doc pretty unequivocally says === By default, an editing context that has no shared editing context listens for DefaultSharedEditingContextWasInitializedNotifications. If a notification is posted while the context has no registered objects, the editing context sets its shared editing context to the newly initialized default shared editing context. === Should it apply for an ERXEC, too? I sort of inferred it would, but by my testing, it does not seem so: an ERXEC I make (through ERXEC.newEditingContext()) seems to adamantly stay without sharedEditingContext, although the notification is posted all right (I have observed it myself to be sure), and if there's a good ole EOEditingContext, it indeed duly sets its sharedEC at the time. Have I missed something of importance somewhere? The ERXEC documentation does not say essentially anything of the sharedEC, far as I can say: http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html In principle, I could work around the problem by setting the sharedEC to all my ERXECs programmatically -- that works all right --, but it would be a lot of work, with a danger I overlook something somewhere and got bit in the tender parts by that... Thanks, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to chill(a)gevityinc.com<mailto:chill@gevityinc.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)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 ocs(a)ocs.cz<mailto:ocs@ocs.cz> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
by ocs＠ocs 29 Aug '18

29 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com 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 <chill(a)gevityinc.com> wrote: > > Finally, an easy question! > > Compatible just means that > modelA.connectionDictionary().equals(modelB.connectionDictionary()) > > Chuck > > From: "ocs@ocs" <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> > Date: Thursday, August 23, 2018 at 7:03 PM > To: Chuck Hill <chill(a)gevityinc.com <mailto:chill@gevityinc.com>> > Cc: "webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>" > <webobjects-dev(a)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 > > <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 <ocs(a)ocs.cz <mailto:ocs@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 <chill(a)gevityinc.com > <mailto:chill@gevityinc.com>> 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 the > EOEditingContext. There is a lot of code in Wonder (and some in WO) that > assumes the defaultWhatever is the only one that will ever exist. You would > have to step into the code to see where this is happening, or enable the > logging of stack traces of fetches. It should be a simple fix once you find > the spot. > > Chuck > > From: "ocs@ocs" <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> > Date: Tuesday, August 21, 2018 at 1:02 PM > To: Chuck Hill <chill(a)gevityinc.com <mailto:chill@gevityinc.com>> > Cc: "webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>" > <webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>> > Subject: Re: Should ERXEC get sharedEC automagically? > > Indeed! If I switch off the OSCPool, it starts to work properly. > > Thanks just again! > > Nevertheless, I still must be missing something of grave importance, for with > OCSPool (I use ), I would presume the SEC for the pool being currently used > by the ERXEC would load the shared objects? > > It does not: the global one does automatically load the shared objects, but > the SEC-based one of ERXEC remains empty. > > Note: the code in question does not run in a session context; it is performed > at launch, before the first session is created. Might that be important > perhaps? > > All the best, > OC > > > > > On 21 Aug 2018, at 9:42 PM, Chuck Hill <chill(a)gevityinc.com > <mailto:chill@gevityinc.com>> wrote: > > Are you using the ERXObjectStoreCoordinatorPool? It keeps one SEC per pool, > not one shared globally. > EOSharedEditingContext.defaultSharedEditingContext() is the global one. > > Chuck > > From: "ocs@ocs" <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> > Date: Tuesday, August 21, 2018 at 12:23 PM > To: Chuck Hill <chill(a)gevityinc.com <mailto:chill@gevityinc.com>> > Cc: "webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>" > <webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>> > Subject: Re: Should ERXEC get sharedEC automagically? > > P.S. It seems ERX completely ignores the default shared EC, using its own > one. If I try e.g., this: > > === > println "The default sharedEC is > ${EOSharedEditingContext.defaultSharedEditingContext()}" > 6.times { > def e=ERXEC.newEditingContext() > println "EC $e gets sec $e.sharedEditingContext" > } > println "The default sharedEC still is > ${EOSharedEditingContext.defaultSharedEditingContext()}" > === > > it looks like this: > > === > The default sharedEC is > com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 > 2005 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - > initializing Pool... > 2008 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - > initializing Pool finished > EC er.extensions.eof.ERXEC@40e32762 gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > EC er.extensions.eof.ERXEC@7d78f3d5 gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > EC er.extensions.eof.ERXEC@f5b6e78 gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > EC er.extensions.eof.ERXEC@71926a36 gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > EC er.extensions.eof.ERXEC@48976e6d gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > EC er.extensions.eof.ERXEC@7f6874f2 gets sec > com.webobjects.eocontrol.EOSharedEditingContext@5875de6a > The default sharedEC still is > com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 > === > > Thanks and all the best, > OC > > > > > On 21 Aug 2018, at 9:07 PM, ocs@ocs <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> wrote: > > Chuck, > > sorry, I did not describe the problem clearly enough... > > > > > On 21 Aug 2018, at 8:39 PM, Chuck Hill <chill(a)gevityinc.com > <mailto:chill@gevityinc.com>> wrote: > Once an EC has objects in it, its shared EC won’t get changed if a new > default is set. The notification is ignored. > > Quite, but that's not the problem. > > With EOEditingContext, it works like this: > > (i) ec created, has no sharedEC (ec.sharedEditingContext==null) > (ii) (due to something which creates a DBContext, I believe) the default > sharedEC is initialized; it loads the shared objects, and sends the > notification > (iii) ec observes the notification, and sets the default sharedEC as its own > sharedEC (for it is still empty) > (iv) now, ec fetches the objects — automatically giving shared ones from its > sharedEC, which does contain them > > With ERXEC (and ERXEC.useSharedEditingContext=true), there's an important > difference: > > (i) erxec created, immediately gets a sharedEC > (ec.sharedEditingContext!=null). This sharedEC differs from the default > shared EC > (ii) (due to something which creates a DBContext, I believe) the default > sharedEC is initialized; it loads the shared objects, and sends the > notification > (iii) erxec (although still empty) does nothing, it already has a sharedEC, > different from the default one > (iv) now, erxec fetches the objects — would automatically give shared ones > from its sharedEC, which, alas, contains nothing (the default one does). > > Thanks and all the best, > OC > > > > > > > From: "ocs@ocs" <ocs(a)ocs.cz <mailto:ocs@ocs.cz>> > Date: Tuesday, August 21, 2018 at 11:21 AM > To: Chuck Hill <chill(a)gevityinc.com <mailto:chill@gevityinc.com>> > Cc: "webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>" > <webobjects-dev(a)lists.apple.com <mailto:webobjects-dev@lists.apple.com>> > Subject: Re: Should ERXEC get sharedEC automagically? > > Chuck, > > > > > > On 21 Aug 2018, at 7:50 PM, Chuck Hill <chill(a)gevityinc.com > <mailto:chill@gevityinc.com>> wrote: > > See er.extensions.ERXEC.useSharedEditingContext at > https://wiki.wocommunity.org/display/documentation/Explanation+of+the+defau… > > <https://wiki.wocommunity.org/display/documentation/Explanation+of+the+defau…> > > Thanks a lot! > > (Why on earth don't they mention this on the ERXEC documentation page? Oh, > never mind.) > > > > > > Did that fix it? > > Well, sort of. > > It gets curiouser and curiouser — in other words, I must be doing something > far wrong. > > When I set the “ERXEC.useSharedEditingContext” property to true, then > > - the newly created ERXEC gets a shared editing context immediately upon > creation, not later upon receiving > DefaultSharedEditingContextWasInitializedNotification; > - and it is a different shared EC instance, not > EOSharedEditingContext.defaultSharedEditingContext() > - but it is EOSharedEditingContext.defaultSharedEditingContext() who reads in > automatically all the shared EOs > - and therefore, when fetching EOs through the ERXEC, I am still getting > non-shared ones in the ERXEC (for its own sharedEC is empty, and thus > EOSharedEditingContext.defaultSharedEditingContext is ignored). > > Can you make any sense of that? > > Thanks again a very big lot, > OC > > > > > > > > On 2018-08-21, 9:43 AM, "Webobjects-dev on behalf of ocs@ocs" > <webobjects-dev-bounces+chill=gevityinc.com(a)lists.apple.com > <mailto:webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com> on behalf > of ocs(a)ocs.cz <mailto:ocs@ocs.cz>> wrote: > > Hi there, > > the EOEditing context doc pretty unequivocally says > > === > By default, an editing context that has no shared editing context listens > for DefaultSharedEditingContextWasInitializedNotifications. If a notification > is posted while the context has no registered objects, the editing context > sets its shared editing context to the newly initialized default shared > editing context. > === > > Should it apply for an ERXEC, too? I sort of inferred it would, but by my > testing, it does not seem so: an ERXEC I make (through > ERXEC.newEditingContext()) seems to adamantly stay without > sharedEditingContext, although the notification is posted all right (I have > observed it myself to be sure), and if there's a good ole EOEditingContext, > it indeed duly sets its sharedEC at the time. > > Have I missed something of importance somewhere? The ERXEC documentation > does not say essentially anything of the sharedEC, far as I can say: > > http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html > <http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html> > > In principle, I could work around the problem by setting the sharedEC to > all my ERXECs programmatically -- that works all right --, but it would be a > lot of work, with a danger I overlook something somewhere and got bit in the > tender parts by that... > > Thanks, > OC > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com > <mailto:Webobjects-dev@lists.apple.com>) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com > <https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com> > > This email sent to chill(a)gevityinc.com <mailto:chill@gevityinc.com> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev(a)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 > <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> > > This email sent to ocs(a)ocs.cz <mailto:ocs@ocs.cz> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?)
by Chuck Hill 27 Aug '18

27 Aug '18

site_archiver(a)lists.apple.com Delivered-To: webobjects-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gevityinc.onmicrosoft.com; s=selector1-gevityinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xSiuTf/drqs9P3FBJpXLGsUidUHoxlA9a7BFb3kl+pg=; b=Y4PJ5iogTa6kpaEX+4xmMQ500/RJsy5u3PG5l4MwVpIW/6vmVYwMU2jz03PtsQo9fqIhWLYhTJy0jDneFS1FNPyOXFvuHq/UaeRQ/Vr5981lnZDwHknKJgMUTQSllzxPuDa9z2IJspJMdtYpDpcSTr1mz9nf/zI0OyBAWbLvsLs= Spamdiagnosticmetadata: NSPM Spamdiagnosticoutput: 1:99 Thread-index: AQHUOhCcCiGDuXdauUezdrE/XVYZIaTOKT+AgARfAgA= Thread-topic: OSCPool/EO stack management/relaunch (was: Should ERXEC get sharedEC automagically?) Finally, an easy question! Compatible just means that modelA.connectionDictionary().equals(modelB.connectionDictionary()) Chuck From: "ocs@ocs" <ocs(a)ocs.cz> Date: Thursday, August 23, 2018 at 7:03 PM To: Chuck Hill <chill(a)gevityinc.com> Cc: "webobjects-dev(a)lists.apple.com" <webobjects-dev(a)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 <ocs(a)ocs.cz<mailto:ocs@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 <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> 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 the EOEditingContext. There is a lot of code in Wonder (and some in WO) that assumes the defaultWhatever is the only one that will ever exist. You would have to step into the code to see where this is happening, or enable the logging of stack traces of fetches. It should be a simple fix once you find the spot. Chuck From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 1:02 PM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? Indeed! If I switch off the OSCPool, it starts to work properly. Thanks just again! Nevertheless, I still must be missing something of grave importance, for with OCSPool (I use ), I would presume the SEC for the pool being currently used by the ERXEC would load the shared objects? It does not: the global one does automatically load the shared objects, but the SEC-based one of ERXEC remains empty. Note: the code in question does not run in a session context; it is performed at launch, before the first session is created. Might that be important perhaps? All the best, OC On 21 Aug 2018, at 9:42 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: Are you using the ERXObjectStoreCoordinatorPool? It keeps one SEC per pool, not one shared globally. EOSharedEditingContext.defaultSharedEditingContext() is the global one. Chuck From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 12:23 PM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? P.S. It seems ERX completely ignores the default shared EC, using its own one. If I try e.g., this: === println "The default sharedEC is ${EOSharedEditingContext.defaultSharedEditingContext()}" 6.times { def e=ERXEC.newEditingContext() println "EC $e gets sec $e.sharedEditingContext" } println "The default sharedEC still is ${EOSharedEditingContext.defaultSharedEditingContext()}" === it looks like this: === The default sharedEC is com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 2005 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - initializing Pool... 2008 [main] INFO er.extensions.eof.ERXObjectStoreCoordinatorPool - initializing Pool finished EC er.extensions.eof.ERXEC@40e32762 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@7d78f3d5 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@f5b6e78 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@71926a36 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@48976e6d gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a EC er.extensions.eof.ERXEC@7f6874f2 gets sec com.webobjects.eocontrol.EOSharedEditingContext@5875de6a The default sharedEC still is com.webobjects.eocontrol.EOSharedEditingContext@26bbe604 === Thanks and all the best, OC On 21 Aug 2018, at 9:07 PM, ocs@ocs <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> wrote: Chuck, sorry, I did not describe the problem clearly enough... On 21 Aug 2018, at 8:39 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: Once an EC has objects in it, its shared EC won’t get changed if a new default is set. The notification is ignored. Quite, but that's not the problem. With EOEditingContext, it works like this: (i) ec created, has no sharedEC (ec.sharedEditingContext==null) (ii) (due to something which creates a DBContext, I believe) the default sharedEC is initialized; it loads the shared objects, and sends the notification (iii) ec observes the notification, and sets the default sharedEC as its own sharedEC (for it is still empty) (iv) now, ec fetches the objects — automatically giving shared ones from its sharedEC, which does contain them With ERXEC (and ERXEC.useSharedEditingContext=true), there's an important difference: (i) erxec created, immediately gets a sharedEC (ec.sharedEditingContext!=null). This sharedEC differs from the default shared EC (ii) (due to something which creates a DBContext, I believe) the default sharedEC is initialized; it loads the shared objects, and sends the notification (iii) erxec (although still empty) does nothing, it already has a sharedEC, different from the default one (iv) now, erxec fetches the objects — would automatically give shared ones from its sharedEC, which, alas, contains nothing (the default one does). Thanks and all the best, OC From: "ocs@ocs" <ocs(a)ocs.cz<mailto:ocs@ocs.cz>> Date: Tuesday, August 21, 2018 at 11:21 AM To: Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> Cc: "webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev(a)lists.apple.com<mailto:webobjects-dev@lists.apple.com>> Subject: Re: Should ERXEC get sharedEC automagically? Chuck, On 21 Aug 2018, at 7:50 PM, Chuck Hill <chill(a)gevityinc.com<mailto:chill@gevityinc.com>> wrote: See er.extensions.ERXEC.useSharedEditingContext at https://wiki.wocommunity.org/display/documentation/Explanation+of+the+defau… Thanks a lot! (Why on earth don't they mention this on the ERXEC documentation page? Oh, never mind.) Did that fix it? Well, sort of. It gets curiouser and curiouser — in other words, I must be doing something far wrong. When I set the “ERXEC.useSharedEditingContext” property to true, then - the newly created ERXEC gets a shared editing context immediately upon creation, not later upon receiving DefaultSharedEditingContextWasInitializedNotification; - and it is a different shared EC instance, not EOSharedEditingContext.defaultSharedEditingContext() - but it is EOSharedEditingContext.defaultSharedEditingContext() who reads in automatically all the shared EOs - and therefore, when fetching EOs through the ERXEC, I am still getting non-shared ones in the ERXEC (for its own sharedEC is empty, and thus EOSharedEditingContext.defaultSharedEditingContext is ignored). Can you make any sense of that? Thanks again a very big lot, OC On 2018-08-21, 9:43 AM, "Webobjects-dev on behalf of ocs@ocs" <webobjects-dev-bounces+chill=gevityinc.com(a)lists.apple.com<mailto:webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com> on behalf of ocs(a)ocs.cz<mailto:ocs@ocs.cz>> wrote: Hi there, the EOEditing context doc pretty unequivocally says === By default, an editing context that has no shared editing context listens for DefaultSharedEditingContextWasInitializedNotifications. If a notification is posted while the context has no registered objects, the editing context sets its shared editing context to the newly initialized default shared editing context. === Should it apply for an ERXEC, too? I sort of inferred it would, but by my testing, it does not seem so: an ERXEC I make (through ERXEC.newEditingContext()) seems to adamantly stay without sharedEditingContext, although the notification is posted all right (I have observed it myself to be sure), and if there's a good ole EOEditingContext, it indeed duly sets its sharedEC at the time. Have I missed something of importance somewhere? The ERXEC documentation does not say essentially anything of the sharedEC, far as I can say: http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html In principle, I could work around the problem by setting the sharedEC to all my ERXECs programmatically -- that works all right --, but it would be a lot of work, with a danger I overlook something somewhere and got bit in the tender parts by that... Thanks, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to chill(a)gevityinc.com<mailto:chill@gevityinc.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)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 ocs(a)ocs.cz<mailto:ocs@ocs.cz> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/site_archiver%40list… This email sent to site_archiver(a)lists.apple.com

1 0