Chuck, > On 21. 9. 2016, at 6:10 AM, Chuck Hill <ch...@gevityinc.com> 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 <o...@ocs.cz> > Date: Tuesday, September 20, 2016 at 6:33 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 2:40, o...@ocs.cz 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 (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
