[ZODB-Dev] Support for graceful ZODB Class renaming

[Jeremy Hylton]

>>>>> "GW" == Greg Ward <gward@mems-exchange.org> writes:

  GW> On 16 January 2003, Jim Fulton said:
  >> 3. A more sophisticated approach is to build a table, stored in
  >>    the
  >> database providing a two-way mapping between a unique id and a
  >> class module and name.  The ids could be assigned automatically.
  >> When pickling a class, we'd pickle the id, rather than the module
  >> and class name. When unpickling a class, we'd lookup the module
  >> and class name in the table.

  GW> This appeals to me for several reasons.  Obviously, making it
  GW> easier to rename classes is a good thing; making this a
  GW> constant-time operation with no complicated/time-consuming
  GW> database churning is even better.

I'm not sure this operation is common enough that it needs to happen
in constant time.  I'm not even sure it needs to happen eagerly.	

  GW> What I like even more, though, is that it adds an explicit
  GW> catalog of all classes in the database to the database itself.
  GW> This appeals to my type-safety, bondage-and-discipline side.
  GW> (See http://www.mems-exchange.org/software/grouch/ .)

Maybe you should be programming in Java <wink>.

  GW> Having a class catalog is nice in itself. But it is also a
  GW> natural place to hang schema information (class x.y.z.C has
  GW> attributes a, b, and c; a is an int, b a list of str, and c an
  GW> instance of foo.bar.FooBar) or other class-centric meta-data
  GW> (eg. the set of all instances of x.y.z.C).

As the complexity of a class catalog grows so does my dislike.  The
catalog needs to be managed more explicitly by the storage, which
makes all storage implementations at least a little more complicated.
It also makes the catalog more fragile.

I think it's important to emphasize the risk of a corrupted catalog.
We have seen periodic reports of corrupted file storages.  It's hard
to say exactly what has gone wrong.  It could be a bug in the
FileStorage code, operator error, flaky hardware, or software bugs in
C libraries, OSes, filesystems, or other components that FileStorage
relies on.  The current storage format is pretty easy to recover from
because each record is largely self-contained, including the module
and name of the object's class.  If you loose a few records, you just
loose a few objects.  If we had a class catalog and the database
happened to get trashed inside catalog records, you could end up
rendering many other objects records useless.

Jeremy