Chuck,
> On 21. 9. 2016, at 10:47 PM, Chuck Hill <ch...@gevityinc.com> wrote:
>
> Ooooooh. I had forgotten about that. Does that qualify as a Heisenbug?
Pretty much, I guess.
Matter of fact, after I found the culprit in one of my test clones, I have
fixed it in the main application... ... ...and the fix did not work. What?!?
D'oh: of course, it could not work, for there still were all those snapshot
logs here and there, through which I have tried to observe the snapshot
creation progress; only after I have removed *all* committedSnapshotForObject's
it started to work properly :)
Incidentally, finding the culprit was sort of at the funny side too.
First I have found in one clone that removing an audit call on user login, it
helps. What?!?
Then, going through the audit code, I found the actual culprit was
===
switch (arg) { // which arg happened to be the user EO
case 'sometext': ...something...
}
===
WHAT?!? Well ... in Groovy, a switch is a bit more flexible than in Java/C; it
effectively boils down to
===
if ('sometext'.equals(arg.toString())) ...something...
===
which indeed causes snapshots not to be filled... well W*H*A*T?!? How can
this... but then, I do override toString for my EOs after all; and eventually I
found that the overridden method in some cases _would_ call
committedSnapshotForObject, so that the EO logs out how it differs from the
saved state. O frabjous day!
Incidentally, is there some simple test which could be used to determine
whether at the place and moment and particular eo it is safe to call
committedSnapshotForObject or not?
Thanks and all the best,
OC
> From: "o...@ocs.cz" <o...@ocs.cz>
> Date: Wednesday, September 21, 2016 at 1:42 PM
> To: Chuck Hill <ch...@gevityinc.com>
> Cc: "webobjects-dev@lists.apple.com WebObjects"
> <webobjects-dev@lists.apple.com>
> Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
>
> Chuck,
>
> On 21. 9. 2016, at 6:10 AM, Chuck Hill <ch...@gevityinc.com> wrote:
> I bet Alice was a developer too.
>
> Beware the EOF, my son!
> The jaws that bite, the claws that catch!
>
> Looks like I have found the culprit — seems it was the very log of the
> committed snapshot. It looks like that if one calls e.g.,
>
> eo.editingContext().committedSnapshotForObject(eo)
>
> at the wrong moment — which did happen to me originally (solely for the
> logging purposes, darnit!), and the more logs I have added, the worse it got
> — one of the not-quite-presumed side-effects of that would be that the
> snapshots do not get properly recorded anymore for eo. Quadruple weird!
>
> When I have removed all the committedSnapshotForObject calls, it starts to
> run properly for all the M:N's, without a glitch. Adding logs immediately
> pre-saveChanges (it seems to be safe at the moment), the snapshot proved to
> be right; and saveChanges sends only the inserts it should.
>
> Matter of fact, we even have bumped to (another presentation of) the very
> same problem some time ago, to wit:
>
> On 28. 2. 2015, at 7:54 PM, Chuck Hill <ch...@gevityinc.com> wrote:
> Ah, Schrödinger’s EOF. :-P Observing some things can materially change the
> state of EOF. Calling this method calls ec.committedSnapshotForObject()
> which causes the EC to record the committed snapshot for the object at that
> point in time. Normally this is done only at the point the EO first changes.
>
> Whew!
>
> Thanks a very big lot for all the help,
> OC
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
