RE: what do we think about this row destroy

[Andy Bierman <abierman@cisco.com>]

At 12:45 PM 11/16/2002 -0800, Dave Thaler wrote:
>> From: Andy Bierman [mailto:abierman@cisco.com]
>>
>> >> I think a better approach would be to return a inconsistentValue
>> >> which should hint to the manager that some other table entries
>> >> in other tables need to be deleted first.
>> >
>> >Was there a good reason in this case why a set to destroy shouldn't
>> >instead have a side effect of changing/deleting the other
>> >RowPointer objects?
>> 
>>  From a programmer's perspective: you never ever NULL out a pointer
>> in use as some side effect.  The code using that pointer only
>> checks for NULL when the pointer is initially set and not before
>> every use of the pointer.
>
>A RowPointer is not necessarily implemented as a pointer.
>I don't see this as much different from deleting a row where
>another table extends the table by using the same INDEX objects
>and possibly more.  Deleting a row in the first table often has
>the side effect of deleting dependent rows in other tables.

A RowPointer is not always used in associated rows in subordinate
tables.  It could be a reference to a row in a table that is
outside the table hierarchy (i.e., an external pointer vs.
a back-pointer).  Deleting a subordinate table that contains
a back-pointer is probably safe.  Deleting or modifying an external
pointer is not safe.


>-Dave

Andy