Underlying DBM format portability
With shelves, the files created by an underlying DBM system used to store your per-
sistent objects are not necessarily compatible with all possible DBM implementations
or Pythons. For instance, a file generated by gdbm on Linux, or by the bsddb library on
Windows, may not be readable by a Python with other DBM modules installed.
This is really the same portability issue we discussed for DBM files earlier. As you’ll
recall, when a DBM file (or by proxy, a shelve) is created, the dbm module tries to import
all possible DBM system modules in a predefined order and uses the first that it finds.
When dmb later opens an existing file, it attempts to determine which DBM system
created it by inspecting the files(s). Because the bsddb system is tried first at file creation
time and is available on both Windows and many Unix-like systems, your DBM file is
portable as long as your Pythons support BSD on both platforms. This is also true if all
platforms you’ll use fall back on Python’s own dbm.dumb implementation. If the system
used to create a DBM file is not available on the underlying platform, though, the DBM
file cannot be used.
If DBM file portability is a concern, make sure that all the Pythons that will read your
data use compatible DBM modules. If that is not an option, use the pickle module
directly and flat files for storage (thereby bypassing both shelve and dbm), or use the
OODB systems we’ll meet later in this chapter. Such systems may also offer a more
complete answer to transaction processing, with calls to commit changes, and automatic
rollback to prior commit points on errors.
Pickled Class Constraints
In addition to these shelve constraints, storing class instances in a shelve adds a set of
additional rules you need to be aware of. Really, these are imposed by the pickle mod-
ule, not by shelve, so be sure to follow these if you store class instance objects with
pickle directly too:
Classes must be importable
As we’ve seen, the Python pickler stores instance attributes only when pickling an
instance object, and it reimports the class later to re-create the instance. Because
of that, the classes of stored objects must be importable when objects are
unpickled—they must be coded unnested at the top level of a module file that is
accessible on the module import search path at load time (e.g., named in PYTHON
PATH or in a .pth file, or the current working directory or that of the top-level script).
Further, the class usually must be associated with a real imported module when
instances are pickled, not with a top-level script (with the module name
main), unless they will only ever be used in the top-level script. You also need
to be careful about moving class modules after instances are stored. When an in-
stance is unpickled, Python must find its class’s module on the module search using
the original module name (including any package path prefixes) and fetch the class
Shelve Files | 1323