Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks
Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks
- Subject: Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks
- From: Philippe Rabier via Webobjects-dev <email@hidden>
- Date: Tue, 14 Jan 2020 11:26:30 +0100
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
> <email@hidden> wrote:
>
> On Jan 13, 2020, at 5:42 AM, OCsite <email@hidden <mailto:email@hidden>> wrote:
>>
>> Chuck,
>>
>>> On 13 Jan 2020, at 4:17, Chuck Hill <email@hidden
>>> <mailto:email@hidden>> 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
>>>> <email@hidden <mailto:email@hidden>>
>>>> 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
>>>>> <email@hidden <mailto:email@hidden>>
>>>>> 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 (email@hidden
>>>>> <mailto:email@hidden>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden
>>>> <mailto:email@hidden>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden>
>>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden