[Zope3-dev] more on class/object lifecycles

[Garrett Smith]

For those who skim, see <ASSERT /> below...

In a prior life, I worked on a Java-based product that uses a component
architecture not dissimilar to Z3's. Early in the product's life, we
used Java serialization to handle persisting object states. There were
problems:

- Just about any change to a class resulted in the inability to load
serialized objects. Even with a *ton* of effort, we could not get around
Java's serialization fragility.

- The inability to load data, for whatever good technical reasons, is
absolutely and unequivocally unacceptable to users.

So, we wrote our own XML based serialization facility, which solved
everything, literally. We were able to recover data from any conceivable
change to the underlying classes.

My guess is that this is one of the main drivers behind alternative
persistent implementations in Zope -- at the end of the day, a
customer's data is in some recoverable format.

But alternative persistence doesn't (appear to) address more iterative
class/object evolution. It still requires a drastic forms of upgrades:
data must be comprehensively updated or else the system is in a *very*
unstable state.

Maybe I'm wrong here -- this is just something I've observed in a very
limited context.

Let me make some assertions, and see if there's resonance out there, or
maybe I'm alone:

<ASSERT>
- Deleting underlying component modules should not necessarily cause an
object deserialization to fail -- something should be able to kick in to
recover an object state.

- Adding a single property to the object scope should not require a
complex upgrade strategy, nor should it require upgrade "cruft" to be
added to the class.

- Changing the name of a class, method, or property should not
necessarily causes deserialization to fail -- again, something should be
able to recover from any errors.
</ASSERT>

While other changes may be less benign than these, I think it should be
possible to perform a variety of updates to objects under the auspices
of class/object evolution.

Perhaps this is a hard problem, or even impossible, and I'm just
engaging in wishful thinking. But the whole "get it right before you
serialize" requirement (lest you're forced to run complex upgrade
scripts, iterating over every object in the ZODB) makes iterative
development very, very difficult and complex.

Sorry for the long note...hope this doesn't come off as a rant. I'm just
curious what people think here -- am I totally off base?

 -- Garrett