I'm worried that versioning is not working properly on my Zope 2.3.0 web site. Since my site is due to receive some major publicity, the flakiness of versioning worries me a good deal. I'm hoping some of the more experienced developers can advise me on whether I should continue to use versioning and/or whether I have a corrupt ZODB. What has been your experience with Versions? Is this a reliable feature of Zope? Here's what happened: I recently committed a Version to the ZODB, but Zope showed many of the objects as still having uncommitted changes (the red diamond). Further, Zope showed many items as having changed that I know for a fact I did not edit (mainly Python scripts). Worst of all, the site became inaccessible to users, with Zope responding to page requests with a VersionLockError. Thankfully, Zope seems to have committed the changes after I saved the Version changes a *second* time, but the fact that Zope got so confused about what had changed makes me reluctant to use versioning in the future. -- Ed Goppelt
Edmund Goppelt wrote:
What has been your experience with Versions? Is this a reliable feature of Zope?
It is, but only in certain circumstances: 1. When people using your site don't need to write to the ZODB to use the site (it sounds like they do in your case) 2. You don't use mounted storages. In particular, Core Session Tracking and Version objects seem to have quite a bad time of it when played with together, but it's understandable when you think about how CST works. I find versions are generally useful when updating brochurewear (DTML Methods and Dcouments) but are limited elsewhere. It's a shame you can't use them with WebDAV (guessing here, somebody tell me I'm wrong ;-) or FTP without major hackory :-S cheers, Chris
On Sun, Mar 25, 2001 at 12:09:10PM +0100, Chris Withers wrote:
1. When people using your site don't need to write to the ZODB to use the site (it sounds like they do in your case)
The users themselves do not write, but periodically an External Method receives email via xml and parses it into a bunch of new Zope objects. Would this cause trouble with Versions?
2. You don't use mounted storages. In particular, Core Session Tracking and Version objects seem to have quite a bad time of it when played with together, but it's understandable when you think about how CST works.
I'm not sure I understand what you mean by mounted storage. The site makes use of LocalFS--is this the kind of thing you are talking about?
I find versions are generally useful when updating brochurewear (DTML Methods and Dcouments) but are limited elsewhere. It's a shame you can't use them with WebDAV (guessing here, somebody tell me I'm wrong ;-) or FTP without major hackory :-S
I'm curious how Versions failed for you when using mounted storage, etc. Were you unable to roll back changes? Were changes you made lost? Was your database corrupted? -- Ed Goppelt
Edmund Goppelt wrote:
On Sun, Mar 25, 2001 at 12:09:10PM +0100, Chris Withers wrote:
1. When people using your site don't need to write to the ZODB to use the site (it sounds like they do in your case)
The users themselves do not write, but periodically an External Method receives email via xml and parses it into a bunch of new Zope objects. Would this cause trouble with Versions?
Yes
2. You don't use mounted storages. In particular, Core Session Tracking and Version objects seem to have quite a bad time of it when played with together, but it's understandable when you think about how CST works.
I'm not sure I understand what you mean by mounted storage. The site makes use of LocalFS--is this the kind of thing you are talking about?
No
I'm curious how Versions failed for you when using mounted storage, etc. Were you unable to roll back changes?
Didn't need to
Were changes you made lost?
Onyl the session data, which is supposed to be temporary anyway.
Was your database corrupted?
No, only the RAM-based mounted storage used by Core Session Tracking. restarting the Zope server solved the problem. cheers, Chris
Chris, can you explain this phenomena a little more (I'll put it in the docs). I *think* you mean that during versioned operations that the sessions written to the RAM database aren't versioned (and they aren't). ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Edmund Goppelt" <goppelt@goppelt.net> Cc: <zope-dev@zope.org> Sent: Sunday, March 25, 2001 10:41 AM Subject: Re: [Zope-dev] Are Versions Reliable?
Edmund Goppelt wrote:
On Sun, Mar 25, 2001 at 12:09:10PM +0100, Chris Withers wrote:
1. When people using your site don't need to write to the ZODB to use
the site
(it sounds like they do in your case)
The users themselves do not write, but periodically an External Method receives email via xml and parses it into a bunch of new Zope objects. Would this cause trouble with Versions?
Yes
2. You don't use mounted storages. In particular, Core Session Tracking and Version objects seem to have quite a bad time of it when played with together, but it's understandable when you think about how CST works.
I'm not sure I understand what you mean by mounted storage. The site makes use of LocalFS--is this the kind of thing you are talking about?
No
I'm curious how Versions failed for you when using mounted storage, etc. Were you unable to roll back changes?
Didn't need to
Were changes you made lost?
Onyl the session data, which is supposed to be temporary anyway.
Was your database corrupted?
No, only the RAM-based mounted storage used by Core Session Tracking. restarting the Zope server solved the problem.
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Chris, can you explain this phenomena a little more (I'll put it in the docs).
Hi Chris, I think it was a documented bug in CST that was causing the problem. Upgrading to CST 0.8 (that was gonna be released soon? ;-) seems to have solved the problem, it also solved the problems with session being randomly dropped. I still got a stack of post-its relating to Python Script grief but I need to get them reproducable before I post :-( cheers, Chris
participants (3)
-
Chris McDonough -
Chris Withers -
Edmund Goppelt