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

[Jim Fulton]

"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.