[bug #18938] Wrong nullify in ToMany relationship

[David Ayers]

Follow-up Comment #3, bug #18938 (project gnustep):

Hi Manuel,  I've spent some time this week debugging this issue and thinking
about how to resolve it best.  I haven't come to a conclusion yet though, so
I think the 2 pass approach is fine for a stop-gap for now.

For documentation sakes, the problem stems from the fact that we process the
changed objects in arbitraty order (which in itself is fine), yet the this
one change actually causes changes in 3 different objects.  One to update the
toOne and two to update the toMany relationships of the affected entities. 
Now depending on which of the two toMany relationships gets processed last,
the attribute is either set to null or the new value.

I've got  two concerns... 
1) This part is where some the most complex processing of GDL2 happens so two
passes seems painfull performance wise but I haven't done any measurements. 
2) I'm still trying to think of complex situatation where we may have more
conflicting changes that overwrite each other.

It may be a non-issue as I've been unsuccessfull in trying to conceive test
cases where mutliple changes / 'legal' reltionships would be consolidated
into more than these 3 changes.  I would feel more comfortable with an
approach that takes the sequence of the changes into account, but this seems
extremly intrusive.

So for now, let's try the two pass approach until we come up with something
better.  I hope to find the time to document the involved methods better and
maybe come up with an approach that allows us to handle this in one pass.

And just for the record, this issue indeed is applicable independent of
whether the foreign key is a class property or whether a
removeObject:fromBothSidesOfRelationshipWithKey: is explicitly set.  It just
happend that adding the calls sometimes changed the order in which the hash
enumerator processed the changes and therefor papered over the issue.

Also please note that the exception with respect to class properties is for
the case of the primary key attribute.  A primary key is immutable and you
can expect the relationships and class properties to be in sync once the
object has been inserted.  But foreign keys of mutable relationships can
change.  Note that if you change the relationship, that the foreign key class
attribute is not updated by GDL2 (nor EOF) until the object is refaulted /
invalidated and refetched.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?18938>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/