Re: More SharedEC woes: relationships into SEC not saved?!?
Re: More SharedEC woes: relationships into SEC not saved?!?
- Subject: Re: More SharedEC woes: relationships into SEC not saved?!?
- From: OCsite via Webobjects-dev <email@hidden>
- Date: Sun, 12 Jan 2020 14:55:59 +0100
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 <Foo@5dbd6e26 PK:1000190> ...
NR [a_id:1000032, b_id:<com.webobjects.foundation.NSKeyValueCoding$Null>]
RD [a_id:1000032]
CH [a:someObject, b:someSharedObject]
AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator =
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 1000032
}; }]
===
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:1000032, b_id:1000001]
... NR [a_id:1000032, b_id:1000001]
... RD [a_id:1000032, b_id:1000001]
AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator =
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 1000032
}; }]
===
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
> <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