[Webware-discuss] WEP: MiddleKit: Deleting objects, ver 2

[Chuck E. <ec...@mi...>]

Here's a new version based on Dave's feedback and my note about invalid 
objects residing in memory.


WEP: MiddleKit: Deleting objects
Author: Chuck Esterbrook
Created: 3/26/2001
Updated: 3/26/2001
Version: 2


BACKGROUND

MiddleKit (MK) already provides for the addition and modification of 
objects that reside in a memory based Python object store which is backed 
by a permanent store, typically a SQL database.

Deleting objects is a functionality that is missing and long overdue.


DELETE AN OBJECT

In Python, you will do this to delete an object:

	store.deleteObject(foo)

This complements the addition of an object to the store:

	store.addObject(foo)

A convenience delete() method could be added to MiddleObject whose 
implementation would essentially be self.store().delete(self). This allows for:

	foo.delete()


Note that in some cases, adding an object to a store happens implicitly. As 
when you do this:

	dept.addToEmployees(employee)

Likewise, deleting sometimes happens implicitly, which leads us to...


DELETE RULES

Reminder: Relationships in MiddleKit are either 1-1 as in 'obj ref', or 
1-many as in 'list'.

Suppose Dept points to Employee as in Dept.employees. You can specify what 
happens to the employees when a department is deleted:

	- detach
	- cascade
	- deny
	- dangle

Explanations:

   detach:  employees stay around and their back reference to
            Dept is set to None.
   cascade: delete the employees too
   deny:    don't allow the dept to be deleted if there are
            employees, e.g., raise exception
   dangle:  very dangerous

So you might have this in Extras:
	onDelete=cascade

Or an onDelete column with the various values.

These delete rules enable the developer to determine in a granular fashion 
what the delete behavior is for any relationship in his object model. As 
usual, this makes the model even more useful for understanding the objects 
of a particular application.

Delete rules may relate to the foreign key capabilities of a specific 
database. Each database adapter in MK is free to implement the most 
appropriate SQL at both design time and run time to enforce constraints and 
implement behaviors. However, SQLObject as it stands will provide this 
behavior at run time for Python programmers.


DELETE OR MARK

By default a model will really delete objects from the permanent store 
(usually a SQL database). An optional behavior is to mark the object as 
deleted so that it still resides in the permanent store, but does not 
appear as the result of any fetches.

The Settings.config file in the model can dictate this behavior:

     'DeleteBehavior': 'mark',  # delete, mark

It is then the responsibility of the application developer to arrange for 
periodic purges of deleted objects. MK object stores will provide 
convenience methods for this, so it can be achieved through a simple Python 
script.

The possibilities for the SQL column for 'mark' could be:
	* A boolean/bit flag
	* A timestamp

Perhaps the choices could be delete, mark flag, mark time.

Another enhancement could include storing the user name that caused the delete.


SAVE CHANGES

As with all changes to the object store, these only take effect when the 
program says:

	store.saveChanges()

Since Python retains objects in memory until they lack effective 
references, the object could still persist in memory despite having been 
removed from the store. This could lead to serious problems if the 
application continues to use the object as if it were legitamate.

To avoid this problem, the store will wipe out the attributes of the object 
and set its __class__ to MiddleKit.Run.DeletedObject which will obviously 
not respond to the messages or return the attributes that the original 
object would. Some debugging info such as the original serial number, etc. 
might be stored in obj.ghost as in obj.ghost['serialNum'], etc.