[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delete
If Ozone adds a delete API it needs to consider the whole scheme of what
to do with deletes on class attributes, especially
w.r.t to any future distributed object scheme for Ozone.
/**
Here is something to think about in any database "delete" operation
(this a generic issue, not specific at all to Ozone):
What do you about "dependents"?
Do you delete the dependents? Do you
recursively cascade deletes on dependents? Do you disallow deletes if
another class contains a reference to it? If so, how do you ever
finally get
rid of all references to an item?
If a class contains a reference to another object,
how are the life-cycles of the 2 objects linked and how is the correct
life-cycle and state
for an object maintained across persistence and distribution?
This turns out to be a highly non-trivial issue for Java (which
currently lacks
distributed object life-cycle services)
since *every* attribute in a class is a dependent and is also just a
reference (the
Java Virtual Machine has life-cycle control of all "new"'d objects!) .
This relates to the whole object-graph serialization problem: If you
really
want to be able to persist and restore a totally functional,
fully-encapsulated object,\
then you must also persist and restore references to all objects used by
the class which conventionally
requires persisting *all* referenced objects. (Remember that Java
object
references cannot generally be resued by an application as they are
meaningful only to the JVM that
created and maintains the object's state.)
When you restore the state of the persisted object, you are now
restoring frozen-state *copies* of the
state of any referenced objects. Those referenced objects, however,
may have been "alive", and maintained
in use and have now have a different state. If so, was your real
intention to synchronize with the pre-existing
"live" objects? If so, was sync'ing should be done
How do you accomplish this when neither a single JVM, much less a
cluster
of cooperating JVM's (distributed Java) can be serialized? Or do you
use user-definable policies to determine what
the intent is? Are these "policies" mutable during the life-time of the
object and if so, how will you maintain
a history of the policy changes?
Now consider several existing solutions to the problem: 1) RDBMS+ SQL
DDL with foreign key references and other constraints
with user-definable policies such as "on delete cascade", " on delete
restrict", " and on delete set null". Log files can handle
policy change history.
Object theorists have much maligned the
set-theoretic basis for SQL, yet SQL has in place the mechanism for
policy-based object-graph serialization, including
deletes and references.
2) The IBM SanFrancisco project (the prototype for EJB) has an elaborate
structure of classes and interfaces by which
independent classes ("Entities" and variations on them) and "Dependent"
references ( always owned by Entities...blah..blah..blah)
were managed by the SF server with named methods ( a syntax-based
sort-of "bean" solution) which enforced delete (not to mention
copy and enternally reference) policies. (Log files here also.)
As far as XML, many of the same issues exist w.r.t XLink and XPointer.
*/
Best Wishes for a happy and prosperous New Year,
Ann Tecklenburg
email: at@ingenuity-sw.com