Spontaneous Namespace Binding Combustion with Script(Python)?
Hi there, Bit of a weird one. Delivered something to a customer last night, went home, came in this morning to find the customer was having problems. I looked at the error: Error Type: TALESError Error Value: exceptions.NameError on global name '_' is not defined in "standard:'here/xxx'", at line xx, column x ...which seemed pretty obvious. I went to the bindings tab of the python script in question and sure enough, the namespace box was empty. Now, the thing is, I _know_ this was bound when I left last night. I checked to see if anyone had edited anything, and nothing had been changed since I left last night, and there were no new transactions in the undo log. So, basically, I'm rather miffed and my confidence is a little shaken. What on earth could have happened here? cheers, Chris
Chris Withers writes:
... I went to the bindings tab of the python script in question and sure enough, the namespace box was empty. Now, the thing is, I _know_ this was bound when I left last night. I like this kind of statements:
FileStorage is a transactional log. Therefore, nothing is lost (unless you packed the database). It can be verified whether or not your statement is right. I had to analyse "Data.fs" twice, to verify similar statements. In both cases, they proved to be wrong. I used "fsdump" and "truncate" in my forensic research... Dieter
Dieter Maurer wrote:
... FileStorage is a transactional log. Therefore, nothing is lost (unless you packed the database).
No packing has been done.
I had to analyse "Data.fs" twice, to verify similar statements. In both cases, they proved to be wrong.
In what way did they prove to be wrong?
I used "fsdump" and "truncate" in my forensic research...
I just used the Undo tab in ZMI. Is it possible for transactions to be committed and not show up in the root undo tab of a ZMI? cheers, Chris
Chris Withers wrote:
Dieter Maurer wrote:
... FileStorage is a transactional log. Therefore, nothing is lost (unless you packed the database).
No packing has been done.
I had to analyse "Data.fs" twice, to verify similar statements. In both cases, they proved to be wrong.
In what way did they prove to be wrong?
I used "fsdump" and "truncate" in my forensic research...
I just used the Undo tab in ZMI. Is it possible for transactions to be committed and not show up in the root undo tab of a ZMI?
Wasn't undoing itself such a transaction before zope 2.5.1? I'm quite sure that at least 2.3.3 worked this way. cheers, oliver
Oliver Bleutgen wrote:
Wasn't undoing itself such a transaction before zope 2.5.1? I'm quite sure that at least 2.3.3 worked this way.
It was, but this is and always has been a 2.5.1 Data.fs cheers, Chris
On Wednesday 25 Sep 2002 9:05 am, Chris Withers wrote:
I just used the Undo tab in ZMI. Is it possible for transactions to be committed and not show up in the root undo tab of a ZMI?
Are there any mounted storages in the picture?
Toby Dickenson wrote:
On Wednesday 25 Sep 2002 9:05 am, Chris Withers wrote:
I just used the Undo tab in ZMI. Is it possible for transactions to be committed and not show up in the root undo tab of a ZMI?
Are there any mounted storages in the picture?
Nope. cheers, Chris
Chris Withers writes:
Dieter Maurer wrote: ...
I had to analyse "Data.fs" twice, to verify similar statements. In both cases, they proved to be wrong.
In what way did they prove to be wrong? Someone said, it was this way and it was not...
I used "fsdump" and "truncate" in my forensic research...
I just used the Undo tab in ZMI. Is it possible for transactions to be committed and not show up in the root undo tab of a ZMI? I did not see this yet (did not look for it, though). But, often transactions maskerade.
In one of the cases above, I analysed why a folder was lost in the ZODB. The most natural way was to look for a "manage_delObjects" inside the containing folder. But, the folder was lost because the containing folder has been deleted and then recreated with an "manage_importObject"; just the imported version did no longer have the missing folder. Dieter
participants (4)
-
Chris Withers -
Dieter Maurer -
Oliver Bleutgen -
Toby Dickenson