Chuck,
thanks again! I did not know that (well one could write a much bigger book than
you did with just those things I do not know...)
Nevertheless, there still must be some ugly fault of mine. When using
objectWithPrimaryKeyValue, there's the superfluous fetch, but it works.
When replaced by faultWithPrimaryKeyValue, I keep getting NPEs somewhere inside
of awakeFromInsertion — at the moment, I can't really make sense of it :( It
looks like this:
===
== about to load 110 from 348ad293 (SEC ) // first time, there's yet no SEC...
4105 [main] DEBUG NSLog - Using JDBCPlugIn
'com.webobjects.jdbcadaptor.FrontbasePlugIn' for JDBCAdaptor@2076611420
... and it is being initialised here; it fetches properly all the shared EOs ...
4110 [main] DEBUG NSLog - connecting with dictionary: {username = "";
password = "<password deleted for log>"; URL =
"jdbc:FrontBase://localhost/SBERDAT3/user=FINServis/isolation=read_committed/locking=optimistic";
}
... ... ... the proper SQL to load all the shared objects here ... ... ...
4235 [main] DEBUG NSLog - === Commit Internal Transaction
... and here's a problem; my overridden awakeFromInsertion logs this just
before a super.awakeFromInsertion:
awakeFromInsertion: <DBDFList@709f0202 PK: N NULL-EC> in
er.extensions.eof.ERXEC@348ad293
... and a log _after_ super does not happen; instead, I get this:
java.lang.Exception:
... ... ...
Caused by: java.lang.NullPointerException
at
er.extensions.eof.ERXGenericRecord.awakeFromInsertion(ERXGenericRecord.java:512)
at
cz.ocs.model.OCSEnterpriseObject.super$4$awakeFromInsertion(OCSEnterpriseObject.groovy)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
... groovy stuff here ...
at
cz.ocs.model.OCSEnterpriseObject.awakeFromInsertion(OCSEnterpriseObject.groovy:265)
// [*]
at
com.webobjects.eocontrol.EOEditingContext.insertObjectWithGlobalID(EOEditingContext.java:2871)
at er.extensions.eof.ERXEC.insertObjectWithGlobalID(ERXEC.java:975)
at er.extensions.eof.ERXEC$insertObjectWithGlobalID$0.call(Unknown
Source)
... groovy stuff here ...
at
cz.ocs.model.OCSEnterpriseObject.staticEOSVM(OCSEnterpriseObject.groovy:164) //
the faultWith... here
===
The awake code looks simply like this:
===
void awakeFromInsertion(EOEditingContext ec) {
println "awakeFromInsertion: ${this} in ${ec}" // this one happens before the
NPE
super.awakeFromInsertion(ec) // [*]
println "supered awakeFromInsertion: ${this} in ${ec}" // we do not get this far
... ... ...
===
Alas, at the moment I have no idea at all what in my code might be the culprit
:(
Thanks and all the best,
OC
> On 22 Aug 2018, at 3:14 AM, Chuck Hill <ch...@gevityinc.com> wrote:
>
> Yes, that makes complete sense. EOUtilities.objectWithPrimaryKeyValue is
> documented to “Fetches the Enterprise Object identified by the specified
> primary key value”. It will fetch. Always. It might not use the fetched
> result, but you asked it to fetch so it will. The method you want is
> faultWithPrimaryKeyValue. That will either resolve the object reference from
> an EO already in the EC, in the shared EC, or in the snapshot cache. If all
> of those fail, only then will it fetch.
>
> And yes, the JavaDocs for faultWithPrimaryKeyValue are wrong (copied from
> objectWithPrimaryKeyValue).
>
>
> Chuck
>
>
> From: "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>>
> Date: Tuesday, August 21, 2018 at 5:15 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: Should loading a shared object try to fetch? (was: Should ERXEC get
> sharedEC automagically?)
>
> 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 <mailto: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
> <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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
