Re: Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?
Re: Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?
- Subject: Re: Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?
- From: Chuck Hill via Webobjects-dev <email@hidden>
- Date: Sun, 12 Jan 2020 19:17:51 -0800
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
> <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
>
> _______________________________________________
> 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