Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[Fabian Peters via Webobjects-dev]

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 
> :
> 
> 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 
>> :
>> 
>> Chuck,
>> 
>>> On 14 Jan 2020, at 6:31, Chuck Hill  wrote:
>>> On Jan 13, 2020, at 5:42 AM, OCsite  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 
>>

Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[Chuck Hill via Webobjects-dev]

Hi OC,

> On Jan 14, 2020, at 9:34 AM, OCsite  wrote:
> 
> Chuck,
> 
>> On 14 Jan 2020, at 6:31, Chuck Hill > > wrote:
>> On Jan 13, 2020, at 5:42 AM, OCsite mailto:o...@ocs.cz>> 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
>>  
>> 
> 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 w

Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[René Bock via Webobjects-dev]

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 
mailto:webobjects-dev@lists.apple.com>>:

Chuck,

On 14 Jan 2020, at 6:31, Chuck Hill 
mailto:hill.ch...@gmail.com>> wrote:
On Jan 13, 2020, at 5:42 AM, OCsite mailto:o...@ocs.cz>> 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 
mailto:webobjects-dev@lists.apple.com>> wrote:

I t

Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[OCsite via Webobjects-dev]

Chuck,

> On 14 Jan 2020, at 6:31, Chuck Hill  wrote:
> On Jan 13, 2020, at 5:42 AM, OCsite mailto:o...@ocs.cz>> 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 
 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 oper

Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[Philippe Rabier via Webobjects-dev]

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 


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 
>  wrote:
> 
> On Jan 13, 2020, at 5:42 AM, OCsite mailto:o...@ocs.cz>> wrote:
>> 
>> Chuck,
>> 
>>> On 13 Jan 2020, at 4:17, Chuck Hill >> > 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
>  
> 
> 
> 
> Chuck
> 
>> 
>> Thanks again a very big lot!
>> OC
>> 
 On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
 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 
 sav

Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[Chuck Hill via Webobjects-dev]

On Jan 13, 2020, at 5:42 AM, OCsite  wrote:
> 
> Chuck,
> 
>> On 13 Jan 2020, at 4:17, Chuck Hill > > 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
 



Chuck

> 
> Thanks again a very big lot!
> OC
> 
>>> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
>>> 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 
 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 datab

Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

[OCsite via Webobjects-dev]

Chuck,

> On 13 Jan 2020, at 4:17, Chuck Hill  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

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.

Thanks again a very big lot!
OC

>> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
>> 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 
>>> 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 SE

Re: Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?

[Chuck Hill via Webobjects-dev]

There must be something going on here that you are not mentioning.  Do you have 
multiple EOF stacks (multiple EOObjectStoreCoordinator instances)?

Chuck


> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
>  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 
>> 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 
>> )
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz 
>> 
>> 
>> This email sent to o...@ocs.cz
> 
> ___

Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

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 
>  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)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
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

Re: More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

Chuck,

> On 12 Jan 2020, at 21:01, Chuck Hill  wrote:
> It only works for code that does  _NSUtilities.classForName().  It only works 
> for code that defers knowing the class based on a string.

I see, so it is the dictionary approach after all. I somewhat hoped they might 
have tweaked the classloader, so that I would be able to patch any class, if 
done right.

Do you perhaps happen to have any insight to the original problem?

I thought the EODatabaseOperation might perhaps try to be smart and refuse to 
operate over another EC, without realising the another EC in fact is the 
current EC's SEC; but I guess in this case it would rather throw an exception 
instead of silently ignoring half of the changes :/

Also, I have checked the EODatabaseContext API just in case there might be 
either a overridable method to create those database operations, or callable 
one to order them, but so far, in vain: all relevant methods seem to be private 
(which, far as I understand Java, means they can be called — with some danger 
—, but can't be overridden); and the one method whose name seems interesting, 
i.e., “NSArray orderAdaptorOperations()”, has no argument, i.e., it does not 
seem to be possible to provide my own list of adaptor operations and ask the 
DBContext to order them.

Darn.

Well of course I can simply simulate what DBContext most probably does (does it 
indeed?), to order adaptor operations using 
“compareAdaptorOperation(EOAdaptorOperation other)”; but I somewhat fear there 
would be some subtle undocumented difference, which would raise its ugly head 
and bite me in tender parts the next month or the next year :/

Thanks and all the best,
OC

>> On Jan 12, 2020, at 7:00 AM, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> P.S.
>> 
>>> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev 
>>> mailto:webobjects-dev@lists.apple.com>> 
>>> wrote:
>>> As for the fixing... well, I guess I can generate the proper AOs myself, 
>>> but the trick is, how do I order them? I would need to reuse the standard 
>>> default ordering which EODatabaseContext does normally; but it does not 
>>> seem to be accessible anyhow, or am I overlooking something of importance 
>>> here?
>> 
>> It looks like
>> 
>> ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
>> ...
>> class OCSDBOperation extends EODatabaseOperation { ... }
>> 
>> does not work :( Do I do something wrong, or it simply can't be overridden?
>> 
>> To be frank, I do not quite understand how the ERXPatcher (or, rather, 
>> _NSUtilities.setClassForName) magic actually works: should it work for any 
>> WO/EO class, or is there simply a dictionary somewhere inside the opaque 
>> Apple code, and it works only for classes which Apple explicitly addresses 
>> by some “Class clazz=dict[name]”, with no way to patch the others?
>> 
>> Thanks!
>> OC
>> 
>> ___
>> 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/hill.chuck%40gmail.com
>>  
>> 
>> 
>> This email sent to 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: More SharedEC woes: relationships into SEC not saved?!?

[Chuck Hill via Webobjects-dev]

It only works for code that does  _NSUtilities.classForName().  It only works 
for code that defers knowing the class based on a string.



> On Jan 12, 2020, at 7:00 AM, OCsite via Webobjects-dev 
>  wrote:
> 
> P.S.
> 
>> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> As for the fixing... well, I guess I can generate the proper AOs myself, but 
>> the trick is, how do I order them? I would need to reuse the standard 
>> default ordering which EODatabaseContext does normally; but it does not seem 
>> to be accessible anyhow, or am I overlooking something of importance here?
> 
> It looks like
> 
> ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
> ...
> class OCSDBOperation extends EODatabaseOperation { ... }
> 
> does not work :( Do I do something wrong, or it simply can't be overridden?
> 
> To be frank, I do not quite understand how the ERXPatcher (or, rather, 
> _NSUtilities.setClassForName) magic actually works: should it work for any 
> WO/EO class, or is there simply a dictionary somewhere inside the opaque 
> Apple code, and it works only for classes which Apple explicitly addresses by 
> some “Class clazz=dict[name]”, with no way to patch the others?
> 
> Thanks!
> OC
> 
> ___
> 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/hill.chuck%40gmail.com
> 
> This email sent to 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

P.S.

> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev 
>  wrote:
> As for the fixing... well, I guess I can generate the proper AOs myself, but 
> the trick is, how do I order them? I would need to reuse the standard default 
> ordering which EODatabaseContext does normally; but it does not seem to be 
> accessible anyhow, or am I overlooking something of importance here?

It looks like

ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
...
class OCSDBOperation extends EODatabaseOperation { ... }

does not work :( Do I do something wrong, or it simply can't be overridden?

To be frank, I do not quite understand how the ERXPatcher (or, rather, 
_NSUtilities.setClassForName) magic actually works: should it work for any 
WO/EO class, or is there simply a dictionary somewhere inside the opaque Apple 
code, and it works only for classes which Apple explicitly addresses by some 
“Class clazz=dict[name]”, with no way to patch the others?

Thanks!
OC

 ___
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

Re: More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

Hello,

I have pursued the problem and it seems to be somewhere at the 
EODatabaseOperation level. Implementing the 
databaseContextWillOrderAdaptorOperations delegate method and logging this:

===
NSArray databaseContextWillOrderAdaptorOperations(EODatabaseContext dbCtxt, 
NSArray databaseOps) {
databaseOps.each {
String op=... a switch to turn it.databaseOperator to a string ... 
incidentally, isn't there a system API for that?
println "-- $op on $it.object ..."
println " NR $it.newRow"
println " RD $it.rowDiffs"
println " CH $it.object.changesFromCommittedSnapshot"
println " AOs -> $it.adaptorOperations"
===

I get for the described case essentially this result:

===
-- UPDATE on  ...
 NR [a_id:132, b_id:]
 RD [a_id:132]
 CH [a:someObject, b:someSharedObject]
 AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator = 
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 132  
}; }]
===

which seems to be the root of the problem. I log CH to make sure the changes 
did not disappear magically: they are still known and all right, thus, the NR 
(and thus also RD and thus also AOs) are wrong.

Note that it does not seem the wrong NR is the only problem; I have tried to 
fix the thing programmatically like this:

===
NSMutableDictionary md=it.newRow.mutableClone()
b_it=it.object.changesFromCommittedSnapshot.b.rawPrimaryKey
println "... -> $md"
it.newRow=md
println "... NR $it.newRow"
println "... RD $it.rowDiffs"
println "... AOs -> $it.adaptorOperations"
===

and got proper RD as expected, but still wrong AOs, as not expected:

===
... -> [a_id:132, b_id:101]
... NR [a_id:132, b_id:101]
... RD [a_id:132, b_id:101]
 AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator = 
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 132  
}; }]
===

Does anybody understand why this happens, and does anybody see how to fix it?

As for the fixing... well, I guess I can generate the proper AOs myself, but 
the trick is, how do I order them? I would need to reuse the standard default 
ordering which EODatabaseContext does normally; but it does not seem to be 
accessible anyhow, or am I overlooking something of importance here?

Thanks and all the best,
OC

> On 11 Jan 2020, at 3:28, OCsite via Webobjects-dev 
>  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)
> Help/Unsubscribe/Update your Subscription:
> 

More SharedEC woes: relationships into SEC not saved?!?

[OCsite via Webobjects-dev]

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)
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