There must be something going on here that you are not mentioning. Do you have multiple EOF stacks (multiple EOObjectStoreCoordinator instances)?
Chuck > On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > I think I have probably solved the original problem (quoted below) all right, > for the record, by doing essentially this in the > databaseContextWillOrderAdaptorOperations delegate method: > > 1. go through all the database operations; for each of them > 2. go through all the relationships of the DBOp object; find those which > lead into SEC > 3. for each such relationship check whether changesFromCommittedSnapshot > contain a value for its name > 4. if so, check whether DBOp's rowDiffs have the proper target PK[*] for > the rel source attribute name (it never seems to happen!) > 5. if not, add it to a mutable copy of DBOp's newRow > 6. having processed all the rels, if anything was added, change DBOp's > newRow and call the DBContext private (ick!) method > createAdaptorOperationsForDatabaseOperation > 7. having processed all the DBOps, call the DBContext private (another ick) > method orderAdaptorOperations and return its value from the delegate method. > > [*] my models happen to contain only simple FK->PK relships to SEC; > considerably more generic and complex code would be needed for all the > possible cases of course. > > That seems to — with by far not exhaustive testing — save the changes into > the database properly. > > Quite non-trivial code for simple > saving-of-relationship-as-set-in-object-graph-into-DB. > > I wonder. Is it perhaps a big no-no to use and edit relationships from normal > ECs into the SEC? I thought those are fully supported (unlike the other > direction). Or do I just do something terribly wrong somewhere in my > application, for this should work all right? > > Does anyone here use this setup (creating/updating EOs with one-way > relationships into SEC), and does it work properly for you without all this > hassle? > > Thanks, > OC > > >> On 11 Jan 2020, at 3:28, OCsite via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> Hi there, >> >> this is weird. My EOs have some relationships into the SharedEC — of course, >> one-way without an inverse; I understand that relationships to SEC are all >> right, only those from it outside are forbidden. (Am I wrong perhaps? If >> those relationships were set up in the database without SEC, it works >> perfectly.) >> >> Nevertheless, when I run with SEC, whatever I try, it seems these >> relationships are — silently and without reporting any problem — not saved. >> >> Say, I have an EO foo of entity Foo with two simple :1 relationships: a >> (based on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a >> shared-EC entity. Both are modelled the same way (simple join from the FK in >> the source entity to the PK of the target entity). I set both of them, like >> this: >> >> === >> ERXEC ec=.... >> Foo foo=new Foo() >> ec.insertObject(foo) >> assert ec==someObject.editingContext() >> foo.a=someObject >> assert ec.sharedEditingContext()==someSharedObject.editingContext() >> foo.b=someSharedObject >> assert foo.b==someSharedObject >> ec.saveChanges() >> === >> >> Now, changes are saved, no error is reported, new object is properly >> inserted into the database >> - its a_id is filled by someObject's PK >> - whilst its b_id is filled by NSKeyValueCoding$Null! >> >> Same happens when editing: the relationships to SEC when changed never seem >> to save the appropriate FK value. It seems completely ignored by the saving >> process: >> >> === >> assert >> foo.editingContext().sharedEditingContext()==anotherSharedObject.editingContext() >> foo.b=anotherSharedObject >> assert foo.b==anotherSharedObject >> assert foo.committedSnapshotValueForKey('b')==NSKeyValueCoding$Null >> assert foo.changesFromCommittedSnapshot==[b: anotherSharedObject] >> foo.editingContext().saveChanges() >> assert foo.b==null >> === >> >> other changes of foo (if any) are saved all right, but its b_id never >> changes. No error is reported. >> >> Does this make any sense, is it perhaps an expected behaviour? As always, I >> might be overlooking something of importance, but this feels completely >> wrong to me. Could it be caused by some bug at my side? If so, any idea >> where and how to hunt for it? >> >> Thanks a lot for any insight, >> OC >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >> >> This email sent to o...@ocs.cz > > _______________________________________________ > 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/hill.chuck%40gmail.com > > This email sent to hill.ch...@gmail.com
_______________________________________________ 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
