On Jan 13, 2020, at 5:42 AM, OCsite <o...@ocs.cz> wrote: > > Chuck, > >> On 13 Jan 2020, at 4:17, Chuck Hill <hill.ch...@gmail.com >> <mailto:hill.ch...@gmail.com>> wrote: >> There must be something going on here that you are not mentioning. > > Definitely there is, but I had no idea what might be the culprit. Now I see > (but still don't quite understand). > >> Do you have multiple EOF stacks (multiple EOObjectStoreCoordinator >> instances)? > > Hmmm... yup, in most of my apps, I use for years and years > > er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=3 > > Let me see, I'll try without ... and just again, you are right! When this is > commented out from Properties, relationships to SEC get saved properly > (without the convoluted databaseContextWillOrderAdaptorOperations delegate of > course). > > Can you please explain how this relates? I must be missing something of > importance, but I can't see any sense in that :( How on earth might the sole > existence of a couple of other (far as I know, pretty independent) EOF stacks > affect the way an EODBOp creates its newRows?!? :-O
I’ve never been much of an SEC user. The EOSharedEditingContext is an EOEditingContext and so it is associated with one EOObjectStoreCoordinator. What I will guess is that the OSC of the SEC instance is != the OSC of the EOEditingContext you are using and there is a bug because the relationship crosses OSCs. I doubt that is fixable, but you might find some way to use that to come up with a better hack. Assuming that I am correct. > Pity I did not know sooner; perhaps I would just switch to use one stack and > save myself all the effort with the searching for the culprit, delegate fixes > attempt etc. > > I do wonder of the speed difference in practice: one coordinator would > definitely make the app somewhat slower; on the other hand, SEC itself should > speed it up, removing a need of many DB roundtrips... hm, perhaps it would be > better just to forget maxCoordinators and stay at the safe side. There is some EO cache in Wonder that I have used instead of the SEC to keep EOs easy to get. I forget the name now. It is not quite as convenient but less magic might yield better results. This might be of use too: https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Caching_and_Freshness#EOEntity's_Cache-In-Memory_Setting <https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Caching_and_Freshness#EOEntity's_Cache-In-Memory_Setting> Chuck > > Thanks again a very big lot! > OC > >>> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto: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 <mailto:o...@ocs.cz> >>> >>> _______________________________________________ >>> 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/hill.chuck%40gmail.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com> >>> >>> This email sent to hill.ch...@gmail.com <mailto: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
