[bugs #8993] Broken validation causes problems with deleteObject:

[David Ayers]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #8993] Latest Modifications:

Changes by: 
                David Ayers <d.ayers@inode.at>
'Date: 
                Wed 05/19/04 at 17:15 (Europe/Vienna)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | ayers


------------------ Additional Follow-up Comments ----------------------------
This is related to bug 3797
https://savannah.gnu.org/bugs/?func=detailitem&item_id=3797
and should be fixed with a large EOEditingContext patch I'm working on, which 
includes effectively a rewrite of the processRecentChanges mechanism.  Yet it 
may still take a bit until it is finished.  If this becomes an issue for 
someone else also, I'll consider interim hacks all the way up to deactivating 
the validation again.






/**************************************************************************/
[bugs #8993] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8993>
Project: GNUstep
Submitted by: Simon Stapleton
On: Tue 05/18/04 at 06:34

Category:  gdl2
Severity:  5 - Average
Item Group:  Bug
Resolution:  None
Assigned to:  ayers
Status:  Open


Summary:  Broken validation causes problems with deleteObject:

Original Submission:  Now that validation is being called when EOEditingContext 
does a saveChanges, a lt of things are fixed.  But a few others appear to be 
broken, notably validation on deleteObject:

What's required:

an existing EO with a mandatory to-one relationship

For example, I have Entity1, let's call it 'Person', which has a personId 
attribute.  I also have Entity2, called 'SalaryHistory'.  This also has a 
personId column.  Person has an optional to-many, owns destination, propagates 
primary key, cascades deletes relationship to SalaryHistory.  SalaryHistory has 
a mandary to-one relationsip to Person.

Now.  I want to delete an existing instance of SalaryHistory.  Let's assume I 
have it already.  My delete code looks like this:

id salaryHistory;
id editingContext;
... get the relevant EO into my EC.
NS_DURING
  {
    [editingContext deleteObject:salaryHistory];
    [editingContext saveChanges];
  }
NS_HANDLER
  [localException raise];
NS_ENDHANDLER

What happens is this:

We mark the object for deletion.  This puts it into _unprocessedDeletes
Then, during _processRecentChanges, we end up removing the object from both 
sides of its relationship to Person.  this sets the personId to nil, using 
takeValue:forKey: and then any accessor that happens to be set for the 
attribute.
As a result of this, the object ends up invoking [self willChange], and it gets 
stuffed into _unprocessedChanges as well.
A little later, we end up calling [EOEditingContext validateChanges].  This 
happily lets the delete through, but barfs on the spurious change, as the 
object has no valid key for the obligatory to-one.  So we raise an exception.

There appear to be two ways to fix this.

One might be to have removeObject:fromBothSidesOfRelationshipWithKey: to use 
takeStoredValue:forKey:, but that would blow normal validation where the object 
is actually being changed, not deleted.  Fiddling with this is likely to get 
complex, and fast.

The approach I have taken is to change [EOEditingContext 
propagatesDeletesUsingTable:] to this:

- (void) propagatesDeletesUsingTable: (NSHashTable*)deleteTable
                         changeTable: (NSHashTable*)changeTable
{
  NSHashEnumerator enumerator;
  id object = nil;

  EOFLOGObjectFnStart();

  enumerator = NSEnumerateHashTable(deleteTable);

  while ((object = (id)NSNextHashEnumeratorItem(&enumerator))) {
    [object propagateDeleteWithEditingContext: self];
    NSHashRemove(changeTable, object);  // Remove the object if it's been added 
to the change table
  }

  EOFLOGObjectFnStop();
}

and the call in _processDeletedObjects to this:

  [self propagatesDeletesUsingTable: _unprocessedDeletes
        changeTable: _unprocessedChanges];

Which seems to solve the problem.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 05/19/04 at 17:15         By: ayers
This is related to bug 3797
https://savannah.gnu.org/bugs/?func=detailitem&item_id=3797
and should be fixed with a large EOEditingContext patch I'm working on, which 
includes effectively a rewrite of the processRecentChanges mechanism.  Yet it 
may still take a bit until it is finished.  If this becomes an issue for 
someone else also, I'll consider interim hacks all the way up to deactivating 
the validation again.

-------------------------------------------------------
Date: Tue 05/18/04 at 11:18         By: tufty
> Then, during _processRecentChanges, we end up removing the object from 
> both sides of its relationship to Person. this sets the personId to nil, 
> using 
> takeValue:forKey: and then any accessor that happens to be set for the 
> attribute. 

Actually, it's setPerson: which gets called, which calls (as it should) 
willChange.  My bad.  However, the net result is the same.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8993>

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