Re: EOF inserts already existing M:N relationships/empty snapshot?!?
Re: EOF inserts already existing M:N relationships/empty snapshot?!?
- Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
- From: "email@hidden" <email@hidden>
- Date: Wed, 21 Sep 2016 13:53:59 +0200
Chuck,
> On 21. 9. 2016, at 6:10 AM, Chuck Hill <email@hidden> 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 overrides
-- 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,
OC
[*] 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 think.
>
> From: OC <email@hidden>
> Date: Tuesday, September 20, 2016 at 6:33 PM
> To: Chuck Hill <email@hidden>
> Cc: "email@hidden WebObjects" <email@hidden>
> Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
>
> Chuck,
>
> On 21. 9. 2016, at 2:40, email@hidden 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden