Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Shane Hathaway]

On Thu, 15 Apr 2004 Jean-Francois.Doyon at CCRS.NRCan.gc.ca wrote:

> What happens is you write a new serializer, notably write a custom
> serializer for an object type you've already been using for a while, using
> the "default" one ? (Presumably because you WANT to be able to access the
> contents from other tools)
> 
> I think I noticed that somewhere in the .properties file there was a note of
> the class used for serializing ... Is there a way for a serialized instance
> to remember which serializer was used ? Or does everything break when I
> change the definition of a serializer (Old instances can no longer be read)
> ?

Ape has a solution.

Every object is stored with a classification.  The classification (a
dictionary of strings, stored in whatever format is chosen by apeconf.xml)  
has at least two keys: class_name and mapper_name.  The mapper_name tells
Ape which mapper was used to store the object, enabling Ape to reliably
use the same mapper to load the object later.  The class_name is used by
mappers that work with multiple classes.

When Ape stores a new state for an object previously loaded, it disregards
the earlier choice of mapper.  So, for example, lets say you've made a
class called UltraPageTemplate, which subclasses ZopePageTemplate.  If you
store that using the default configuration, Ape won't try to guess how you
meant to store it and will mostly just pickle it.  The mapper_name will be
"anyfile".

Later, you add to apeconf.xml a mapper that specifically serializes
UltraPageTemplate objects, using the mapper_name
"Products.UltraPT.UltraPT.UltraPageTemplate".  Ape will continue to load
UltraPageTemplates stored using the "anyfile" mapper because the
mapper_name supercedes the class_name when loading.  However, when you
store new UltraPageTemplates or update existing ones, Ape will use your
new mapper, since the old choice of mapper is not consulted at save time.  
Therefore, to update all existing instances of UltraPageTemplate to use
your new mapper, you only need to get ZODB to load all the existing
instances and store them again unchanged.  If your new mapper is 
complete, the old pickles will go away and people will be able to edit 
UltraPageTemplates outside Zope.

Using strategies like this, Ape is trying to achieve a mode of development
that doesn't require you to decide how to store objects at the same time
you write classes.  You start with ZODB, a radically simple, unintrusive
storage layer, then you customize gradually with Ape.  I think Ape is 
making good progress toward that goal.

Shane