Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Steve Alexander
Chris McDonough wrote: I am +1 on this. I suspect that before committing, though, we should ask people who make use of Zope's transaction manager in advanced ways like Phillip Eby. As I noted in the Collector issue, I believe this change is a good idea overall. As Chris suggests, we should

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Toby Dickenson
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote: This is flawed as error handling is done outside of a transaction. Excellent analysis. A futher problem is that this could cause dangling references, and a subsequent POSKeyError, since persistent objects can be passed from one

[Zope-dev] Running Python Scripts via the Management Interface

2003-02-03 Thread Asad Habib
Hello. Does anyone know why the following script stalls when I run it in Zope's Management Interface using the 'Test' command? context.manage_addProperty(propertyId, propertyValue, propertyType) All it does is add a property to a folder. The script does function properly and doesn't stall when

[Zope-dev] Re: [Zope] Running Python Scripts via the Management Interface

2003-02-03 Thread Geir Bækholt
on or about, Monday, February 03, 2003, we have reason to believe that Asad Habib wrote something along the lines of : Hello. Does anyone know why the following script stalls when I run it in Zope's Management Interface using the 'Test' command? context.manage_addProperty(propertyId,

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Steve Alexander
Chris McDonough wrote: I am +1 on this. I suspect that before committing, though, we should ask people who make use of Zope's transaction manager in advanced ways like Phillip Eby. I've spoken to Phillip Eby, and he sees no problem with the approaches we've discussed. So, +1 from me. --

RE: [Zope-dev] ESI Integration in Zope

2003-02-03 Thread Brian Lloyd
Out of curiosity, Beyond coding XHTML-based ZPTs with tags in the ESI namespace, what else is needed in Zope to make this work? Does Zope need to set an HTTP header for downstream proxies to know that the content of the page is supposed to be processed for ESI? Sean You won't need to

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Chris McDonough
All that's fine by me, and allowing an error handler to have side effects explicitly is probably a good idea... will anybody volunteer to do this for 2.7? - C On Mon, 2003-02-03 at 03:44, Steve Alexander wrote: By conincidence I'm implementing something similar for error handling in Zope 3

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Jeremy Hylton
Your basic point makes sense, although I'm not entirely clear on how transaction management is integrated into the Zope application. Speaking for ZODB alone, I believe we've recommended that people call get_transaction().abort() if they catch an exception. I can't recall getting into any nuances

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Joachim Werner
Toby Dickenson schrieb: On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote: This is flawed as error handling is done outside of a transaction. Excellent analysis. A futher problem is that this could cause dangling references, and a subsequent POSKeyError, since persistent objects can

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Toby Dickenson
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote: Zope's current transaction behaviour is essentially: 1 ## request starts 2 transaction.begin() 3 try: 4object= REQUEST.traverse(...) 5mapply(object,...) 6transaction.commit() 7 except: 8

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Chris McDonough
On Mon, 2003-02-03 at 11:11, Joachim Werner wrote: We are heavily depending on sessions, so the scenario you are describing could be our problem. Are you making a reference to a session (or another persistent object) in your standard_error_message? If not, this is probably not the problem. -

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Dieter Maurer
Toby Dickenson wrote at 2003-2-3 17:04 +: On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote: Zope's current transaction behaviour is essentially: 1 ## request starts 2 transaction.begin() 3 try: 4object= REQUEST.traverse(...) 5

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Dieter Maurer
Jeremy Hylton wrote at 2003-2-3 10:45 -0500: ... Note that a new transaction is begin implicitly any time a persistence object is referenced. So the error handling code does execute in the context of a transaction. I know... It may be that it's just not the transaction you'd like it

Re: [Zope-dev] Why is it _setObject(), and why is it undocumented

2003-02-03 Thread Leonardo Rochael Almeida
On Sat, 2003-02-01 at 12:16, Max M wrote: Lennart Regebro wrote: From: maxm [EMAIL PROTECTED] Usually a private method is used purely as a mean of implementation. And should never be called from other objects. This is not the case here, as the method is clearly a part of the api.

Re: [Zope-dev] [Bug] Zope's transaction behaviour flawed

2003-02-03 Thread Dieter Maurer
Toby Dickenson wrote at 2003-2-3 10:40 +: On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote: This is flawed as error handling is done outside of a transaction. Excellent analysis. A futher problem is that this could cause dangling references, and a subsequent POSKeyError,

[Zope-dev] ZODB3 3.1.1b2

2003-02-03 Thread Barry A. Warsaw
We've made another beta release of ZODB 3.1.1 available, including ZEO 2.0.2. This is primarily a bug fix release; see the NEWS.txt file excerpt below for details. Of particular note are the enabling of the BTrees-based index for FileStorage and the disabling of the rare hosed state in ZODB.