> On 21. 9. 2016, at 6:10 AM, Chuck Hill <> wrote:
> I bet Alice was a developer too.

> Have you overridden any of the EOF methods, or the generated methods in User 
> or DataBlock and changed the normal behavior?  Or forgotten to call super?

Note please that there's more M:N's in that application, and other ones work 
all right (although, as outlined below, their changes never occur in the 
DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method; the 
snapshot though is all right).

As for overridden methods, let me see...

- my EO root is an OCSEnterpriseObject (which extends ERXGenericRecord), and 
-- awakeFromInsertion to set up creation date; calls super
-- validateForSave; calls super (and does not change the eo :))
-- handleQueryWithUnboundKey and handleTakeValueForUnboundKey: these do not 
call super (which is all right I think)
-- toString (does not call super either)
- DataBlock (extends OCSEnterpriseObject) does not override anything (and works 
all right with other M:N's)
- User ditto

No accessors are implemented explicitly in DataBlock or User[*].

That aside, I install a DatabaseContextDelegate. It extends 
ERXDatabaseContextDelegate, and overrides 
databaseContextWillPerformAdaptorOperations to log what is about to happen with 
the database and databaseContextFailedToFetchObject, again to log which 
object/gid did fail. None of them calls super. Temporarily I tried to override 
databaseContextShouldUpdateCurrentSnapshot to log when and how the snapshot is 
updated, but with M:N's it does not seem to work -- I have never got any M:N in 
its new dict (although most M:N's work all right and the appropriate snapshots, 
logged just-before-save, contain the proper eos).

Can I track somehow (e.g., through some delegate methods/notifications) when 
and how exactly the snapshot :N's gets updated? Looks like 
databaseContextShouldUpdateCurrentSnapshot is not the right way to do that. At 
least, my last attempt obtained all the :N names from the entity and would log 
out if any of them is either in the old or in the new dict -- but never logs 
anything (whilst attributes and :1 changes go through here all right).

Thanks and all the best,

[*] There are no generated sources like _User or _DataBlock in my setup; the 
accessor methods are injected launch-time into User/DataBlock/all other EO 
classes based on model contents. In my personal opinion, this approach 
(conceptually copied down from Core Data) is much cleaner and considerably less 
error-prone than generated sources. Should not be relevant to this problem, I 

> From: OC <>
> Date: Tuesday, September 20, 2016 at 6:33 PM
> To: Chuck Hill <>
> Cc: " WebObjects" 
> <>
> Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
> Chuck,
> On 21. 9. 2016, at 2:40, wrote:
> Aside of that, I have added a log into the 
> DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, 
> and here I *never* get *anything* for the relationships: neither the old 
> (which is presumable) *nor the new* dictionary ever contain the 
> “userDataBlocks” or “dataBlockUsers” key — not once.
> well this one's weird, or I am missing something of importance here.
> Meantime, I have played with another M:N, which works without a glitch (and 
> which is modelled the same way as that one which does not, incidentally). 
> Here, save-time, the snapshot does contain the proper related objects (and 
> thus proper INSERTs are generated).
> The weird thing is that these objects *do not* come into the snapshot through 
> the DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot 
> method! It logs all right when the object is fetched, but the new (nor the 
> old, of course) dictionary does *not* contain the relationship key at all -- 
> precisely the same way it is with that relationship which does not work 
> properly!
> Nevertheless, as mentioned above, save-time, the snapshot is all right. 
> Couriouser and couriouser, Alice would say :-O
> Thanks and all the best,
> 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