"Jay, Dylan" wrote:
Now for my rant. How on earth did I get in this situation???? There are two serious problems here. 1) How on earth did an object get overridden by a completely different object.
An external methd could do it. External methods are dangerous in many ways. I'd like to hear more about the one you were debugging. I'd also like to see your database so I can try to figure out what happened. (Please *just* send your database to support@digicool.com, not the entire Zope list.)
This might have something to do with object id's getting mixed up????
I don't think so.
In any case its a really big bug and as I'm not sure when or how it happened I'm not sure how we can fix it.
So we'd like to figure it out with you.
2) It is a seriously problem if anything in the ODB can prevent zope starting. Since zope is only method of accessing the ODB then it can't be fixed (easily) unless Zope can be brought back up.
Zope isn't exactly the only way to access the ODB, but we certainly don't provide any other easy ways. One thing we should do is provide a script for doing undo from the command line so that fatal transactions can be undone.
It seems to me that much more care should be taken to find any unhandled exceptions in the zope init sequence. I disliked the idea of a putting all my data into some closed repository. I am completely left helpless if I want to rollback any changes in situations like this.
This is a key point. You should be able to roll back changes even if the database is down. I'll provide a tool for doing this next week.
There should be an intergration into a source control repository like CVS. Something that is file based so data can be manually edited.
I don't think that this has anything to do with CVS. It would be nice to be able to inspect and edit the database with a text editor. We are working on a database<-->XML tool that will allow exactly that.
Also is there anyway to reduce the dependence of the main zope functionality on states kept inside the ODB?
Yes, up to a point.
ie in this case is it necessary to keep persistant information on all the Products in the ODB?
Yes, but we can do a better job of reacting to problems. We are working on this. For example, there is a change in Product.py in the 2.0 source that is very similar to the fix you figured out yourself.
In short, Zope needs to be crash proof. How can we make this happen?
- We can do a better job at catching and handling errors in critical parts of Zope (like initialization). - We may want to consider disallowing external methods, or giving much sterner warnings about their use. - We can provide better tools for managing or manipulating the database when Zope does not want to come up. For example, we should provide a tool for undoing changes from the command line. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.