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

[Jay, Dylan]

> -----Original Message-----
> From: Paul Everitt [mailto:paul@digicool.com]
> Sent: Sunday, June 13, 1999 13:33
> To: Jay, Dylan
> Cc: 'zope@zope.org'
> Subject: Re: [Zope] RE: URGENT: Can't start up zope
> 
> 
> 
> "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?

What your getting at here is true. The storage format is only a small part
of the problem. As it turned out in this case it wasn't the format but
sematics of the data that was at fault. Having a relational or XML version
would not have made a differece. My bad feeling really comes from combining
code and data idea. The ZODB is really acting as a repository for code,
documents that make up static content of the site and database type
information unless you choose to put that in a relation DB. It makes me
uneasy to put code and data in the same place. It seems to me that this is
what Zope is all about though.
What would mitigate the risk is to have a proper encapsulation. External
methods are essential however python is not an encapsulated language in the
same way something like java is. Encapsulation would prevent bugs
interferring with anymore than with what they are supposed to interact with?
Is this possible with python? And if not what are the possibilities of
moving to a language that does?
 
> 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?