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: Chuck Hill via Webobjects-dev <email@hidden>
- Date: Mon, 13 Jan 2020 21:31:36 -0800
On Jan 13, 2020, at 5:42 AM, OCsite <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