-----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?