|
[Webware-discuss] WEP: MiddleKit: Deleting objects, ver 2
From: Chuck Esterbrook <echuck@mi...> - 2001-03-27 05:08
|
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.
|
| Thread | Author | Date |
|---|---|---|
| [Webware-discuss] WEP: MiddleKit: Deleting objects, ver 2 | Chuck Esterbrook <echuck@mi...> |