Re: Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?
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?!?
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
