[Zope] RE: URGENT: Can't start up zope

[Paul Everitt]

"Jay, Dylan" wrote:
> Also is there anyway to reduce the dependence of the main zope functionality
> on states kept inside the ODB? ie in this case is it necessary to  keep

Jim made a very good reply, I'll add in a couple more blurbs as well.

First, you're right, we need to continue doing everything we can to
improve the reliability as well as provide tools for recovery.  I can
safely say Jim et al. are _keenly_ engaged on this.  But like security,
reliability isn't one silver bullet, it is a collection of options.

Thus, we need you and others to keep brainstorming more ways to get
there.

As for the database itself, IMO there are two issues involved: storage
of the objects and the objects themselves.

In the first case, the current Zope database is responsible for managing
records in a file.  If something goes wrong, records might get mangled. 
Zope2 will let you have replacement options with other storage managers
you might trust more, like a gdbm/bsddb file, a relational database,
etc.  Zope2 also has a more resilient database format, as well as an
option to partition your object system into multiple storages (thus
minimizing any damage)*.

In the second case, at the end of the day the object data will be in a
Python pickle.  This means that the object data is still intimately tied
to the application -- which is at the heart of object oriented
programming.  Of course the XML import/export of the database helps
mitigate this.

Thus my question: How much would allowing record storage and management
in something you might trust (e.g. bsddb) alleviate the black-box
feeling?

Needless to say, the gang here at DC, particularly Jim, are mighty
interested in what you think on the subject.

* Perhaps the top-level folder in Zope2 should be in its own storage, so
that changes to sub-subobjects won't be in danger of corrupting it? 
Just a thought?

--Paul