Hi all, I would bet on your answer, Chuck. And I agree w/ you: I don’t remember the details but we had some side effects/issues in the past w/ SEC
OC, I recommend an article titled "Development-Which cache to use with EOs?" I wrote several years ago: https://wiki.wocommunity.org/pages/viewpage.action?pageId=12943886 <https://wiki.wocommunity.org/pages/viewpage.action?pageId=12943886> I do not code in java for a while but I just checked and Guava cache still exists. I think It could help you in several use cases like setting a relationship with a “parameter” entity. We made this research because we were in a context of hundred of requests/s so we wanted to minimize roundtrips between WO app and database. And it worked very well. Best, Philippe > On 14 Jan 2020, at 06:31, Chuck Hill via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > On Jan 13, 2020, at 5:42 AM, OCsite <o...@ocs.cz <mailto: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/prabier%40icloud.com > > This email sent to prab...@icloud.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
