I've installed the latest XMLWidget, but find I'm having problems with deleting an earlier instance. I can't seem to do anything to undo the changes as these fail. I'm also getting horrible messages of the form 1999-10-14T23:57:14 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000\005f' how can I fix up my database? -- Robin Becker
Robin Becker wrote:
I've installed the latest XMLWidget, but find I'm having problems with deleting an earlier instance.
Hm, my install document says to uninstall the previous incarnation, because otherwise you'll have problems like this. :) But it's no disaster, I'm sure.
I can't seem to do anything to undo the changes as these fail. I'm also getting horrible messages of the form
1999-10-14T23:57:14 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000\005f'
how can I fix up my database?
I've seen that kind of message before, though not in association with XMLWidgets (I will probably see 'm if I consult the logfile, though :). I think it means the ZODB finds an object it can't find an associated class for, or something like that. It doesn't seem to harm anything, at least, though all the \000\ stuff *looks* scary. That said, I'd like to know what to do about orphan objects like that. I've created a number of them when changing around XMLWidgets. Twice I removed some code (a widget class, for instance), but then found out I couldn't delete/move/do anything to the ZClasses that were previously instantiated and expected this code to be there. The trick I used was to recreate the class (empty), and then I could delete the object. Now probably there's already some script in the utilities directory that does the trick... Hm, looking at it you might be able to use bbb.py to generate a report on what transaction caused the mess, and then manually truncate your database to a state before that. Trouble is that you'd need the original XMLWidgets installed to remove them cleanly; removing the .py code before you remove the objects that use it isn't a good idea (it gets you into problems like this). In general, some tools/advice to deal with this kind of problem would be appreciated. [Turns to stare hopefully at Digital Creations] Regards, Martijn
Martijn Faassen wrote:
Now probably there's already some script in the utilities directory that does the trick... Hm, looking at it you might be able to use bbb.py to generate a report on what transaction caused the mess, and then manually truncate your database to a state before that.
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't work on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration). Regards, Martijn
In article <19991015023035.A13088@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> writes
Martijn Faassen wrote:
Now probably there's already some script in the utilities directory that does the trick... Hm, looking at it you might be able to use bbb.py to generate a report on what transaction caused the mess, and then manually truncate your database to a state before that.
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't work on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration).
Regards,
Martijn
... I exported out all the good bits and then re-initialised my db. I knew that I had to delete things, just forgot a particular instance. Overall a real pain. Incidentally even after I deleted the xmlwidget subtree of Products I stll saw a fake XMLWidgets product in zope. I was unable to delete the product. What's the correct way to remove a product? -- Robin Becker
Robin Becker wrote:
I exported out all the good bits and then re-initialised my db. I knew that I had to delete things, just forgot a particular instance. Overall a real pain.
Agreed. Having thought about this some more this may in fact be a Zope bug. If the broken ZClass instances had shown up as a broken product instances one could've simply removed them; but somehow they don't turn into broken objects but into mysterious indestructible ones. I can see some cases where this may be hard to prevent, but ..well, Digital Creations input would be appreciated here. (hints again)
Incidentally even after I deleted the xmlwidget subtree of Products I stll saw a fake XMLWidgets product in zope. I was unable to delete the product. What's the correct way to remove a product?
Hm, did you remove the Product in the product management screen first, and then removed the XMLWidgets folder, and then restarted Zope? Removing XMLWidgets .py files first and then removing the product won't work; if you did do it in the order I suggested it is weird though. Thanks for trying out XMLWidgets, by the way. I wish it wasn't so much trouble for you, though! Regards, Martijn
In article <19991015160301.B14669@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> writes OK I'll try and remember to delete products the right way round. I have now tried to reinstall the product, but I keep having problems. I can get the demo to import, but it looks like it's broken. Do I have to do an import as well as the extract into Products (like the previous version)? I have copied Node.py into XMLDocument. -- Robin Becker
Robin Becker wrote:
In article <19991015160301.B14669@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> writes OK I'll try and remember to delete products the right way round.
I have now tried to reinstall the product, but I keep having problems. I can get the demo to import, but it looks like it's broken. Do I have to do an import as well as the extract into Products (like the previous version)? I have copied Node.py into XMLDocument.
Hm, unless I did something wrong, you should do this: * Remove any old XMLWidgets installation you had. You've done this * Install xmlwidgets-0.2.tgz in lib/python/Products. Restart Zope * Install the ZClasses xmlwidgets-zclasses-0.2.zexp in the product management screen. This is easier than in the previous version; it makes a new product called XMLWidgetsZClasses * Now install the demo xmlwidgets-demo-0.2.zexp somewhere else in the tree. I thought my installation document explained this, though. Was something unclear? Does it not work this way? I am sorry to cause all this trouble! Regards, Martijn
In article <19991015174355.A15057@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> writes
Robin Becker wrote:
In article <19991015160301.B14669@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> writes OK I'll try and remember to delete products the right way round.
I have now tried to reinstall the product, but I keep having problems. I can get the demo to import, but it looks like it's broken. Do I have to do an import as well as the extract into Products (like the previous version)? I have copied Node.py into XMLDocument.
Hm, unless I did something wrong, you should do this:
* Remove any old XMLWidgets installation you had. You've done this
* Install xmlwidgets-0.2.tgz in lib/python/Products. Restart Zope
* Install the ZClasses xmlwidgets-zclasses-0.2.zexp in the product management screen. This is easier than in the previous version; it makes a new product called XMLWidgetsZClasses
* Now install the demo xmlwidgets-demo-0.2.zexp somewhere else in the tree.
I thought my installation document explained this, though. Was something unclear? Does it not work this way? I am sorry to cause all this trouble!
Regards,
Martijn OK I was trying to import inside the XMLWidgets product. Now all is clear and much better than previously. -- Robin Becker
In article <19991015023035.A13088@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> wrote:
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't work on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration).
Have a look at The Tranalyzer on www.zope.org.
In article <940257033.960673@fezzik.endicor.com>, Ty Sarna <tsarna@endicor.com> writes
In article <19991015023035.A13088@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> wrote:
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't work on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration).
Have a look at The Tranalyzer on www.zope.org.
... I just tried tranalyser and it gives an error on my Data.fs and also on Data.fs.in C:\Python\devel\Zope\var>python ..\utilities\tranalyzer.py -r Data.fs.in TID: 3292AD04EEDD74D obs 4 len 712 By [Zope] "" OID: 6 len 121 OID: 4 len 123 OID: 9 len 61 OID: 3 len 224 1513 21750 ****** TRUNCATED TRANSACTION at 4: TID: 3292AD04EEDD74D obs 4 len 712 By [Zope] "" OID: 6 len 121 OID: 4 len 123 OID: 9 len 61 OID: 3 len 224 C:\Python\devel\Zope\var> I'm running under win32 -- Robin Becker
Robin Becker wrote:
In article <940257033.960673@fezzik.endicor.com>, Ty Sarna <tsarna@endicor.com> writes
In article <19991015023035.A13088@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> wrote:
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't work on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration).
Have a look at The Tranalyzer on www.zope.org.
... I just tried tranalyser and it gives an error on my Data.fs and also on Data.fs.in
[snip output] Hm, I'm afraid I can't help you much with this output; it doesn't tell me a lot. Perhaps Ty Sarna has an idea what to do now? I still have to try the tranalyser myself. Regards, Martijn
In article <380C2FCD.95335E59@vet.uu.nl>, Martijn Faassen <m.faassen@vet.uu.nl> writes
Robin Becker wrote:
In article <940257033.960673@fezzik.endicor.com>, Ty Sarna <tsarna@endicor.com> writes
In article <19991015023035.A13088@vet.uu.nl>, Martijn Faassen <faassen@vet.uu.nl> wrote:
Okay, I was wrong. :) I just tried bbb.py and this won't work; it won't
work
on ZODB 3. I imagine Digital Creations could have some hacked up ZODB 3 reporting/manipulation tools lying around. If so perhaps it'd be a good idea to release some of them (if only so we can study the source code for inspiration).
Have a look at The Tranalyzer on www.zope.org.
... I just tried tranalyser and it gives an error on my Data.fs and also on Data.fs.in [snip output]
Hm, I'm afraid I can't help you much with this output; it doesn't tell me a lot. Perhaps Ty Sarna has an idea what to do now? I still have to try the tranalyser myself.
Regards,
Martijn
... It's a bit worrying that Data.fs.in has a problem though. Makes me wonder if my CVS isn't bringing the file down in binary mode. -- Robin Becker
It's a bit worrying that Data.fs.in has a problem though. Makes me wonder if my CVS isn't bringing the file down in binary mode.
Just downloaded Tranalyzer. Change the 'r' on line 296 to 'rb' and it should be fixed. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
In article <4.2.0.58.19991019173301.00bb5350@lisp.atmm.nl>, Martijn Pieters <mj@antraciet.nl> wrote:
It's a bit worrying that Data.fs.in has a problem though. Makes me wonder if my CVS isn't bringing the file down in binary mode.
Just downloaded Tranalyzer. Change the 'r' on line 296 to 'rb' and it should be fixed.
Aha. My Unix bias shows again :-) The version on zope.org is now fixed.
participants (5)
-
Martijn Faassen -
Martijn Faassen -
Martijn Pieters -
Robin Becker -
tsarna＠endicor.com