[ZODB-Dev] Schema definition

[Tim Peters]

[Paolo Losi]
> I'm back again :-)
> stop me if you think you had enough :-)

We never get too much here <wink>.

> I'm defining complex objects (lots of attributes).
>
> Instead of using the standard approach:
>
> class Test:
> 	def __init__(self, a1=None, a2="Default Value):
> 		self.a1 = a1
> 		self.a2 = a2
>
> I'm thinking of:
>
> Class Test:
> 	a1 = None
> 	a2 = "Default"
> 	def __init__(self,**kargs):
> 		for attribute in kargs.keys():
> 			setattr(self,attribute,kargs[attribute])
>
> This allows me to avoid writing the same attribute name three times :-)
>
> Do you see any drawbacks?

Well, the obvious ones:  the latter is harder to read, and has poorer
prospects for self-documentation and error-checking (e.g., a user can pass
any keywords at all to the Test constructor in the second form without
getting an error; the same mysteriousness will also frustrate tools like
pychecker).

> Does there exist a common practice for schema definition?

This is an entirely different question, right?  A good overview of
approaches and their drawbacks, and a not yet implemented proposal for
another approach can be found here (sorry, you'll probably have to paste
this URL together again):

<http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/DatabaseGe
nerations>

The biggest things to watch out for at first are consequences of Python's
approach to pickling (serialization), most of which ZODB inherits (although
it's arguable that large parts of Python's pickling design were equally
driven by ZODB):  modules and classes are pickled "by name" (strings giving
the module and class names).  If you have a persistent object that contains
one of your Test instances above, then you've got headaches if you want to
rename Test, or if you want to move the definition of Test into a different
module.  The pickles in the database expect to find a class named "Test" in
the module from which Test was originally obtained, and there's no painless
way to convince old pickles that Test has been moved or renamed.

OTOH, because the class implementation code is not stored in the database,
things like adding new attributes are usually easy.

> Does there exist a "zodb best practices" document?

This is a must-read if you're using FileStorage:

    http://zope.org/Wikis/ZODB/FileStorageBackup