> On 21. 9. 2016, at 10:47 PM, Chuck Hill <> 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,

> From: "" <>
> Date: Wednesday, September 21, 2016 at 1:42 PM
> To: Chuck Hill <>
> Cc: " WebObjects" 
> <>
> Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
> Chuck,
> On 21. 9. 2016, at 6:10 AM, Chuck Hill <> 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 <> 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      (
Help/Unsubscribe/Update your Subscription:

This email sent to

Reply via email to