"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