In a moment of stupidity, while trying to get rid of an object gone horribly wrong (I couldn't get into my zmi for some reason, with "Attribute Error" on a particular object that *did* exist), I did:
del(app.stupid_object) get_transaction().commit()
Well, of course that didn't fix my zmi problem, and now I couldn't get at the offending object... so I did
app.stupid_object="anything" app._delObject("stupid_object") get_transaction().commit()
... and now it's gone, and I can get into the ZMI. Now for the question: the old stupid_object was folderish and contained a lot of subobjects. What happens to these objects? Are they still floating around in my ZODB since I never did any kind of proper _delObject() on their container? I just did del() on it, and I don't know if that takes care of removing sub-objects from the ZODB (seems doubtful). If they're still around, is there any way to find and get rid of them? -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
On Wednesday 25 Sep 2002 2:53 pm, Paul Winkler wrote:
If they're still around, is there any way to find and get rid of them?
It depends on the storage
Now for the question: the old stupid_object was folderish and contained a lot of subobjects. What happens to these objects? Are they still floating around in my ZODB since I never did any kind of proper _delObject() on their container? I just did del() on it, and I don't know if that takes care of removing sub-objects from the ZODB (seems doubtful).
If this is FileStorage, then you have committed a couple of transactions that modified the top level object. Unless you have packed, the old objects are still intact. The best option would be to undo your manual transactions, and get back to your original state. If this is something like bsddbStorage.packless, then the old objects are likely to have been garbage collected.
On Wed, Sep 25, 2002 at 02:59:56PM +0100, Toby Dickenson wrote:
On Wednesday 25 Sep 2002 2:53 pm, Paul Winkler wrote:
If they're still around, is there any way to find and get rid of them?
It depends on the storage
Plain old FileStorage.
If this is FileStorage, then you have committed a couple of transactions that modified the top level object. Unless you have packed, the old objects are still intact.
That's what I thought, but how do I find a reference to them?
The best option would be to undo your manual transactions, and get back to your original state.
I can't find anything in Undo that will bring this object back. Remember, I got rid of it with del(app.stupid_object). There's no Undo for that. I did confirm that the sub-objects are around - I found a transactoin for a sub-object and successfully did Undo on it. So, knowing the ID of the object, is there a way to find a valid reference to it so I can do a real _delObject() on it? -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
On Wednesday 25 Sep 2002 3:19 pm, Paul Winkler wrote:
I can't find anything in Undo that will bring this object back. Remember, I got rid of it with del(app.stupid_object). There's no Undo for that.
Sure there is. Every transaction is undoable. If you didnt register a url for your transaction then Zope's undo log wont show it in the gui..... you will have to call the undoLog method yourself to find a reference to the transaction, then call transactionalUndo.
So, knowing the ID of the object, is there a way to find a valid reference to it so I can do a real _delObject() on it?
Why do you think that will help?
On Thu, Sep 26, 2002 at 11:17:01AM +0100, Toby Dickenson wrote:
On Wednesday 25 Sep 2002 3:19 pm, Paul Winkler wrote:
I can't find anything in Undo that will bring this object back. Remember, I got rid of it with del(app.stupid_object). There's no Undo for that.
Sure there is. Every transaction is undoable.
If you didnt register a url for your transaction then Zope's undo log wont show it in the gui..... you will have to call the undoLog method yourself to find a reference to the transaction, then call transactionalUndo.
It took a while to find the methods; I had to make a copy of the database (this is a live site), run a python prompt, import teh ZODB module, and do this:
fs = ZODB.FileStorage.FileStorage('/zope/InstanceHome/var/Data.fs.OLD') ul = fs.undoLog(first=0, last=140) def sort_by_time(u1, u2): return cmp(u1['time'], u2['time']) ul.sort(sort_by_time) ul.reverse()
Now I've got a list of the 120 most recent undoable transactions, sorted by time (starting with most recent). I can verify this by looking at them:
for u in ul: print u['time'], u['user_name'], u['description']
What's troubling is that I can find the last time I modified the object in question in this log, and there are *no* transactions later than that which could possibly be my del(app.foo). So unless I've misunderstood what you told me to do, it looks like you're wrong. I don't understand how this can be, because I did app.get_transaction().commit() which I would think would put something in the undo log. What am I missing? Here's the list (edited for redundancy) - the object I deleted was /marketing, a Plone site, and you can see me doing manage_properties on a subobject at transaction 23 in this list.
for i in range(0, 24): print i, ul[i]['time'], ul[i]['user_name'], ul[i]['description'] ... 0 1033019507.02 Anonymous User /ct/about/privacy.dtml/HEAD 1 1032980355.99 mberg /nzt/PhPortal/portal_framework_header/manage_edit
(snip - items 2-21 are much the same as item 1) 22 1032963600.46 admin /bupsync/manage_addXMLRPC 23 1032963314.04 paulw /manage_undo_transactions Undo 2002/09/24 19:28:47.122 Universal /marketing/portal_skins/plone_forms/manage_properties
So, knowing the ID of the object, is there a way to find a valid reference to it so I can do a real _delObject() on it?
Why do you think that will help?
Because that's what I'm really trying to do. I asked if >>> del(app.marketing) would delete sub-objects of marketing, and was told no, they're still in my ZODB. There's about 10-20 MB of this crap that I can't get at now, and I want it gone. *If* I can undo the del(), then I can do a proper manage_deleteObjects([marketing]) which I think will get rid of the sub-objects. That's what I should have done in the first place. As I said, doing del(app.marketing); get_transaction().commit() was a stupid thing that I never should have done, but it's too late. If I can't undo that transaction, I want to know if there's another way to find and delete the objects that were under app.marketing after I've done del(app.marketing). Make sense? -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
On Thursday 26 Sep 2002 6:54 pm, Paul Winkler wrote:
Now I've got a list of the 120 most recent undoable transactions, sorted by time (starting with most recent).
correct.
What am I missing?
no idea. :(
So, knowing the ID of the object, is there a way to find a valid reference to it so I can do a real _delObject() on it?
Why do you think that will help?
Because that's what I'm really trying to do. I asked if >>> del(app.marketing) would delete sub-objects of marketing, and was told no, they're still in my ZODB. There's about 10-20 MB of this crap that I can't get at now, and I want it gone.
If you want to recover the disk space then all you have to do is pack.
*If* I can undo the del(), then I can do a proper manage_deleteObjects([marketing]) which I think will get rid of the sub-objects.
Yes, it will 'properly' get rid of them. That means notifying all contained objects that they are about to be deleted so that, for example, they can remove themselves from a ZCatalog. However it wont immediately reduce disk space - even a manage_deleteObjects can be undone..... until you pack.
On Fri, Sep 27, 2002 at 08:05:15AM +0100, Toby Dickenson wrote:
If you want to recover the disk space then all you have to do is pack.
(smacks hand against head) ok. I am officially brain-dead. --PW -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
participants (2)
-
Paul Winkler -
Toby Dickenson