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: Wed, 15 Jan 2020 08:41:44 -0800
Hi OC,
> On Jan 14, 2020, at 9:34 AM, OCsite <email@hidden> wrote:
>
> Chuck,
>
>> On 14 Jan 2020, at 6:31, Chuck Hill <email@hidden
>> <mailto:email@hidden>> wrote:
>> On Jan 13, 2020, at 5:42 AM, OCsite <email@hidden <mailto: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?
Yes, that is the one.
> 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.)
It was a long time ago (10 years?) and I don’t have the code available to me
now, but I recall doing something like that to make the GID->object conversion
quick. I recall it did not quite work the way I expected or wanted.
> 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
>>
>> <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.
Each OSC would have its own copy. The sessions would just have references. It
would use more memory but would not have a copy of the row data per session.
>
> Perhaps it was a wrong decision and the memory waste would be a cost well
> worth of not bumping into those SEC quirks...
It is difficult to know at this point.
Chuck
>
> Thanks again,
> 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