Re: caching global IDs does not work as expected (followup: ordered and filtered fault efficiency)
Re: caching global IDs does not work as expected (followup: ordered and filtered fault efficiency)
- Subject: Re: caching global IDs does not work as expected (followup: ordered and filtered fault efficiency)
- From: OC <email@hidden>
- Date: Mon, 16 Feb 2015 10:40:45 +0100
Chuck,
On 15. 2. 2015, at 21:07, Chuck Hill <email@hidden> wrote:
>> (a) get a fault instead of the object itself -- this is self-evidently wrong, for the object has been added into the EC short time ago, and the documentation says “If the object associated with globalID is already registered in this EOEditingContext ... this method returns that object”
>
> The fault is the EO, or should be.
Unlike it used to be with the crystal-clear ObjC, I don't fully understand the Java messy implementation of (lots of things including) faults, but my understanding is that still the following does apply:
(a) a fault would very probably have same hashCode as the EO it stands for
(b) definitely, it would occupy the “same space” in JVM, making thus sure pointers to it (in the Java highly confusing lingo „object variables“) don't need to change when it gets fired
(c) before it was fired(=fetched from DB), isFault==YES (in other words, isFault==YES implies that when used, it will be fired)
(d) once fetched, isFault=NO, and until refaulted/invalidated/garbage collected, won't be fetched again.
> If it is not in the EC, it will return true to isFault() but calling willRead() will fire the fault, populating the data in the EC. If the object was added to the EC, then it should be returned.
And very definitely its isFault should return NO, unless I am very wrong.
Which it does not:
===
> ???? about to get _EOIntegralKeyGlobalID[DBPriceOffer (java.lang.Integer)1000275] of <DBAuction@422562876 PK:1000015 E:2 Title:'blah' /EC:1655327563> /EC:1655327563
> ???? got 1165696376 isfault: true
===
> If it is not, then something in your app is very, very, very wrong.
Indeed, it stinks by that to the high heaven. But what could be the problem, and how to find it?
> I am also starting to suspect this from some of your other messages.
Indeed, my other problem might well be related -- to recap, that ec.saveChanges() invalidates some relationships (looks like those which target the entity whose contents has been changed by the save).
> Very not normal. It not even normal to try and fetch it if it has been added to the EC already. It should only fetch if the snapshot is not there or the timestamp on the snapshot is before the EC’s fetchTimestamp.
Another good point: as soon as I get back to this, along with the objects hashCodes and relationship isFaulty condition I'm going to log also the snapshots.
And perhaps their timestamps too, but I don't know where to find them? I can get snapshot dictionaries from the EC or from the DatabaseContext, but I can't find any method to get a timestamp associated with one of those?
> Is permanentGlobalID something that you wrote?
Nope, it's a Wonder API (actually I did not even know of it until Ramsey pointed it to me about a fortnight ago). Pre-Wonder, I never had anything like permanentGID, and for reference I have used my primaryKeyNumericValue (whose code, pretty primitive at that, I have attached previously, and which indeed does not work at all before an object gets saved).
> The global ID is based on the PK so the PK value must be known.
Self-evidently it is not -- not just through my own old primaryKeyNumericValue, but also through Wonder's primaryKey method:
> ===
> println "po PK:${po.primaryKeyNumericValue()} / WPK:${po.primaryKey()}"
> println "po perm: ${po.permanentGlobalID()}"
> println "po PK:${po.primaryKeyNumericValue()} / WPK:${po.primaryKey()}"
> ===
>
> logs out these results:
>
> ===
> po PK:-2 / WPK:null
> po perm: _EOIntegralKeyGlobalID[DBPriceOffer (java.lang.Integer)1000277]
> po PK:-2 / WPK:null
> ===
(more complete source and longer log in previous e-mail, along with primaryKeyNumericValue source)
> Are you creating the GID with the PK but not setting it on the EO?
Never -- far as I can say. There's only one place I create a GID myself -- this is the old version of my application, where I can't get rid of the legacy code where manual management of PKs more or less stands for shared editing context, and I am creating some EOs using the following code:
=== [*]
def object=new SomeEOClass()
if (object!=null) {
ec.insertObjectWithGlobalID(object,EOKeyGlobalID.globalIDWithEntityName(ename,[primaryKey]))
... fill its attributes etc. ...
}
===
nevertheless,
(a) correct me please if I am wrong, but I believe this is the right way which sets the GID for the EO all right;
(b) besides, it _never_ happens with those entities I am having problems with: we are seeing weird behaviour of DBAuction, DBPriceOffer and perhaps DBUser, and the above PK-madness happens only for _different_ entities;
(c) and even that happened long ago: the objects are created only when not found in the DB (to find them, I use "EOUtilities.objectWithPrimaryKeyValue"). They were created and stored long ago, actually, the [*] code has not been used at all this year :)
so it seems to me highly improbable this might be the culprit.
> That might cause EOF to generate a different PK when you save and then GID != PK value which could lead to some of the results you are seeing.
I never bumped into GID!=PK, unless PK was null. What happens to me is that
(a) newly created EO, whose PK is (of course) null, gets entered into EC -- so far so good;
(b) weird thing 1: if I use Wonder's permanentGlobalID, I get the GID all right, but eo.primaryKey() remains null?!?
(c) weird thing 2 (might be related): faultForGlobalID(permanentGlobalID) returns a fault (isFault=YES), not the object entered in (a)
(d) weird thing 3 (definitely related): when willRead that fault, DB SELECT is performed with the right PK (the one from permanentGlobalID in (b)); of course it finds zilch, for the object was not saved yet, and databaseContextFailedToFetchObject delegate method gets called;
(e) natural thing (but should not happen at all): when databaseContextFailedToFetchObject returns false, the right EO -- the one created and inserted at (a) -- occurs at the place of the former fault. At this moment, it _does_ have the PK (as logged out through Wonder's primaryKey).
> Wonder does this correctly, check the implementation there.
Well I am using that implementation -- both permanentGlobalID and primaryKey come from Wonder, I have not overridden any of them. Nor have I overridden faultForGlobalID (offhand I am not sure whether Wonder overrides it; if not, it's the original Apple code).
Note: I still don't know whether there is anything as “Wonder version“ and if there is, where to find it, but as a work-around, I am logging out CFBundleShortVersionString from the Info.plist of the ERExtensions.jar, and it reads 6.1.3-SNAPSHOT -- should be reasonably up-to-date.
> I will try and find time to read more later.
Thanks a very big lot!
all the best,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden