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: Fabian Peters via Webobjects-dev <email@hidden>
- Date: Thu, 16 Jan 2020 10:22:09 +0100
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
> <email@hidden>:
>
> 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
>> <email@hidden>:
>>
>> Chuck,
>>
>>> On 14 Jan 2020, at 6:31, Chuck Hill <email@hidden> wrote:
>>> On Jan 13, 2020, at 5:42 AM, OCsite <email@hidden> 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
>>>>>> <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> 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)
>>>>>>> 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
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>
> 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 (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