Hi René, Just to avoid anybody else getting confused like I got: You removed the conditional that checked that property in a second commit back then. So the fix is active in any wonder version younger than 2018-09-04.
cheers, Fabian > Am 15.01.2020 um 11:53 schrieb René Bock via Webobjects-dev > <webobjects-dev@lists.apple.com>: > > Hi, > > if you are using multiple ObjectStores in one WO-Application, you should set > > er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer.localNotifyOfRemoteUpdates > = true > > > to ensure, that changes are propagated between the different object stores. > Because of Wonder Issue #866, you should use a rather fresh version of Wonder > ( > 17-7-2018) > > >> Am 14.01.2020 um 18:34 schrieb OCsite via Webobjects-dev >> <webobjects-dev@lists.apple.com>: >> >> Chuck, >> >>> On 14 Jan 2020, at 6:31, Chuck Hill <hill.ch...@gmail.com> wrote: >>> On Jan 13, 2020, at 5:42 AM, OCsite <o...@ocs.cz> wrote: >>>>> 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. >> >> As always, indeed, correct you are. >> >> Since my app makes sure to use only one of all the coordinators for the >> normal work and for sessions (keeping the rest of coordinators from the pool >> solely for my background tasks), I was pretty sure this can't happen... >> until I tried to log out the coordinators, and indeed, they did differ. >> Seems the SEC coordinator gets assigned in some weird way. >> >> With fixing, I am afraid I am outta luck; one possibility would be to get >> rid of the SEC altogether, another probably the delegate hack which works >> around the problem — for having revisited the app meantime, alas, I recalled >> I can't do without those extra coordinators for the background tasks. Some >> of them could write many objects into DB, and alas, I can't let the users in >> normal sessions wait for that long :( >> >>>> 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. >> >> For the moment, I am using both. The EO cache you mean would probably be >> ERXEnterpriseObjectArrayCache? I am using the thing pretty widely to cache >> normal EOs to lower the number of DB roundtrips needed (nevertheless it >> seems the turning the cached GIDs to objects is rather at the slow side too, >> and I am considering to extend the code to try to cache the objects >> themselves while there's a memory galore in some sort of a weak map — >> incidentally, to all, has someone already tried that? I haven't found this >> kind of cache in ERX; either it does not exist, or I have searched >> improperly.) >> >> SEC serves for my „static“ objects, which are never changed (more precisely, >> they might be changed in a special task upon launch, before the first >> session is created; and never ever again). A majority of these „static“ >> objects then are shared by essentially all sessions — in my current >> application there's lots of those, which is also the very reason I have >> started to use SEC at all (for the first time in twenty-odd years of using >> WO ;)) >> >> For this very reason I would rather like to keep the SEC, far as it proves >> manageable; but of course, we'll see... >> >>> This might be of use too: >>> https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Caching_and_Freshness#EOEntity's_Cache-In-Memory_Setting >> >> Thanks! I have considered that, too; but I have eventually chosen SEC >> because it not only caches, but also ensures the objects are actually shared >> betw. all sessions. Far as I understand, in-memory entities would cause each >> session to have its own full cache of all the „static“ objects, which might >> be a bit of a memory problem with more users working with the app at once. >> >> Perhaps it was a wrong decision and the memory waste would be a cost well >> worth of not bumping into those SEC quirks... >> >> Thanks again, >> OC >> >>>>>> 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> 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) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> 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/bock%40salient-doremus.de >> >> This email sent to b...@salient-doremus.de > > Mit freundlichen Grüßen > > René Bock > > -- > Telefon: +49 69 650096 18 > > salient GmbH, Lindleystraße 12, 60314 Frankfurt > Telefon Zentrale: 069 / 65 00 96 - 0 | www.salient-doremus.de > > _______________________________________________ > 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/lists.fabian%40e-lumo.com > > This email sent to lists.fab...@e-lumo.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
