Even without ERXObjectStoreCoordinatorPool, there's another strange behaviour.
I happen to be loading my objects (many of which happen to be in the SEC) using
“EOUtilities.objectWithPrimaryKeyValue”.
If the object happens to be in the SEC, I get it all right, but when I switch
on SQL log, it looks like it is fetched anyway?!? I.e., something like this:
===
println "== about to load $pk from $ec.identityHashString (SEC
$ec.sharedEditingContext.identityHashString)"
def foo=ec.sharedEditingContext.objectsByEntityName[ename].find {
it.rawPrimaryKey==pk }
if (foo!=nil) println " it IS pre-loaded in SEC: $foo"
//object=EOUtilities.objectWithPrimaryKeyValue(ec,ename,pk)
object=ERXEOControlUtilities.objectWithPrimaryKeyValue(ec,ename,pk,NSArray.EmptyArray,NO,NO)
println " got $object"
===
logs out something like
===
== about to load 101 from 25673087 (SEC a7cf42f)
it IS pre-loaded in SEC: <DBDFList@3a4aadf8 PK:101 SEC:a7cf42f>
4663 [main] DEBUG NSLog - === Begin Internal Transaction
4663 [main] DEBUG NSLog - evaluateExpression:
<com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "SELECT
t0."C_DESCRIPTION", t0."C_CREATION_DATE", t0."C_CREATOR_ID", t0."C_IDENTIFIER",
t0."C_CONTENT_DATA", t0."C_MODIFICATION_DATE", t0."C_TITLE", t0."C_UID" FROM
"T_DF_LIST" t0 WHERE t0."C_UID" = 101" withBindings: >
4664 [main] DEBUG NSLog - 1 row(s) processed
4665 [main] DEBUG NSLog - === Commit Internal Transaction
got <DBDFList@3a4aadf8 PK:101 SEC:a7cf42f>
===
Happens even with a
“ERXEOControlUtilities.objectWithPrimaryKeyValue(...,NSArray.EmptyArray,false,false)”
instead.
Does it make any sense? I would presume that with the desired object in the
SEC, no database roundtrip should be needed (and done) at all?
Thanks and all the best,
OC
> On 21 Aug 2018, at 10:02 PM, ocs@ocs <o...@ocs.cz> wrote:
>
> 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 <ch...@gevityinc.com
>> <mailto:ch...@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" <o...@ocs.cz <mailto:o...@ocs.cz>>
>> Date: Tuesday, August 21, 2018 at 12:23 PM
>> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
>> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
>> <webobjects-dev@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 <o...@ocs.cz <mailto:o...@ocs.cz>> wrote:
>>
>> Chuck,
>>
>> sorry, I did not describe the problem clearly enough...
>>
>>
>> On 21 Aug 2018, at 8:39 PM, Chuck Hill <ch...@gevityinc.com
>> <mailto:ch...@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" <o...@ocs.cz <mailto:o...@ocs.cz>>
>> Date: Tuesday, August 21, 2018 at 11:21 AM
>> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
>> Cc: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>"
>> <webobjects-dev@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 <ch...@gevityinc.com
>> <mailto:ch...@gevityinc.com>> wrote:
>>
>> See er.extensions.ERXEC.useSharedEditingContext at
>> https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project
>>
>> <https://wiki.wocommunity.org/display/documentation/Explanation+of+the+default+properties+in+a+Wonder+project>
>>
>> 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....@lists.apple.com
>> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on
>> behalf of o...@ocs.cz <mailto:o...@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@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 ch...@gevityinc.com <mailto:ch...@gevityinc.com>
>>
>> _______________________________________________
>> 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
>> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz>
>>
>> This email sent to o...@ocs.cz <mailto:o...@ocs.cz>
> _______________________________________________
> 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 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
