getPersistentItemIDs not cooperating?
Has anyone seen anything like this? I have the following script in a Specialist: ## Script (Python) "deleteAllTracks" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title= ## trackMaster=context.Tracks import string iList=[] for id in trackMaster.defaultRack.getPersistentItemIDs(): iList.append(id) theItem=trackMaster.getItem(id) iList.append(theItem.manage_delete()) return "OK! deleted:" + string.join(iList,',') It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage. Thoughts? The only way I ever create Track objects is via a different method that is only accessed once (a long time ago!) thanks, -steve
Hi!
It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage. Thoughts? The only way I ever create Track objects is via a different method that is only accessed once (a long time ago!)
Well, I experiences something similar when changing a Racks storage from persistent to non-persistent. The included objects are marked as orphaned then and should be deleted with the Clear-Button. This also works, but only the half of them gets deleted every time I click on that button.. So I also have to press it several times.. Sounds like the same problem.. cheers, Christian -- COM.lounge http://comlounge.net/ communication & design info@comlounge.net
At 05:48 PM 5/23/01 +0200, Christian Scholz wrote:
Hi!
It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage. Thoughts? The only way I ever create Track objects is via a different method that is only accessed once (a long time ago!)
Well, I experiences something similar when changing a Racks storage from persistent to non-persistent. The included objects are marked as orphaned then and should be deleted with the Clear-Button. This also works, but only the half of them gets deleted every time I click on that button.. So I also have to press it several times.. Sounds like the same problem..
I just thought of how this happens... if you delete an object from the Rack, it's being removed from the virtual list of keys your loop is traversing. So as you iterate from 0..n, and you delete items from the rack, they are removed from the keys list too, the list shortens, and every other item in the list is skipped! This is why you get half the list every time. The fix would probably be: foo = getPersisentItemIDs() while foo: foo[0].manage_delete() I should probably do this in ZPatterns too. I'm working on upgrading it for 2.3.2 right now anyway.
Hi Phil, Yup.. I realized it when I could *list* all the ids, but not delete them. ;-) I'm wondering if it might be better to change the implementation of getPersistentItemIDs to return a plain list? This would also help avoid permission errors that folks run in to when trying to use it in dtml. I realize that listifying takes time, but you probably wouldn't call it if you had a very large number of items in the rack (you'd maybe query a catalog or something else.. ) -steve On Wednesday, May 23, 2001, at 11:22 AM, Phillip J. Eby wrote:
At 05:48 PM 5/23/01 +0200, Christian Scholz wrote:
Hi!
It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage. Thoughts? The only way I ever create Track objects is via a different method that is only accessed once (a long time ago!)
Well, I experiences something similar when changing a Racks storage from persistent to non-persistent. The included objects are marked as orphaned then and should be deleted with the Clear-Button. This also works, but only the half of them gets deleted every time I click on that button.. So I also have to press it several times.. Sounds like the same problem..
I just thought of how this happens... if you delete an object from the Rack, it's being removed from the virtual list of keys your loop is traversing. So as you iterate from 0..n, and you delete items from the rack, they are removed from the keys list too, the list shortens, and every other item in the list is skipped! This is why you get half the list every time.
The fix would probably be:
foo = getPersisentItemIDs()
while foo: foo[0].manage_delete()
I should probably do this in ZPatterns too. I'm working on upgrading it for 2.3.2 right now anyway.
Hi Phil, FYI.. this doesn't work in a PythonScript since indexing into a BTreeItems is (apparently) not allowed by the "Security Machinery". So... a simple list is looking better and better! ;-) -steve On Wednesday, May 23, 2001, at 11:22 AM, Phillip J. Eby wrote:
The fix would probably be:
foo = getPersisentItemIDs()
while foo: foo[0].manage_delete()
I should probably do this in ZPatterns too. I'm working on upgrading it for 2.3.2 right now anyway.
At 12:33 PM 5/23/01 -0500, Steve Spicklemire wrote:
Hi Phil,
FYI.. this doesn't work in a PythonScript since indexing into a BTreeItems is (apparently) not allowed by the "Security Machinery". So... a simple list is looking better and better! ;-)
Hmmm. Good point. I'll have to think about that one. I just hate to load all those keys if they're not really needed. I suppose if you call getPersistentItemIDs(), you usually want them all... It's just that if you use the BTreeItems object, it can toss out keys that aren't needed. Maybe what I'll do is implement a wrapper over BTreeItems that fixes this somehow. I'll also have to look at how this works with the new "BTrees" trees, because I *know* they don't implement indexing the same way, and may not have this problem!
Steve Spicklemire wrote:
Has anyone seen anything like this? <snip> It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage.
Yes, I've seen this. It's on my list of things to look into when I've got a certain large project out of the way :-/
Thoughts?
Well, getPersistentItemIDs() just returns the result of calling keys() on the Rack's BTree. I guess it is a problem with the BTree code. I doubt it'll be fixed though. Instead, we should update Rack to use the new BTrees module. -- Steve Alexander Software Engineer Cat-Box limited
Well.. it turned out to be more subtle. It goes back to the old problem that getPersistentItemIDs doesn't return a real list, but rather a BTreeItems object. When you call manage_delete on *one* item, it affects the BTreesItems object you are iterating over! This works: ## Script (Python) "deleteAllTracks" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title= ## trackMaster=context.Tracks import string iList=[] for id in trackMaster.defaultRack.getPersistentItemIDs(): iList.append(id) dList=[] for id in iList: theItem=trackMaster.getItem(id) theItem.manage_delete() dList.append(id) return ("OK! deleted %i elements" % len(iList)) + string.join(iList,',') On Wednesday, May 23, 2001, at 10:59 AM, Steve Alexander wrote:
Steve Spicklemire wrote:
Has anyone seen anything like this? <snip> It works.. partially. For some reason it looks like getPersistentItemIDs does not always return a *complete* list. I need to run this method several times to completely exhaust the Rack's storage.
Yes, I've seen this. It's on my list of things to look into when I've got a certain large project out of the way :-/
Thoughts?
Well, getPersistentItemIDs() just returns the result of calling keys() on the Rack's BTree.
I guess it is a problem with the BTree code.
I doubt it'll be fixed though. Instead, we should update Rack to use the new BTrees module.
-- Steve Alexander Software Engineer Cat-Box limited
_______________________________________________ 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 )
Steve Spicklemire wrote:
Well.. it turned out to be more subtle.
It goes back to the old problem that getPersistentItemIDs doesn't return a real list, but rather a BTreeItems object. When you call manage_delete on *one* item, it affects the BTreesItems object you are iterating over!
Right... another one of those "it returns a mutable internal object" problems. In that case, is there a security problem with what getPersistentItemIDs returns being accessible to TTW scripting? I'm changing the OS on my development machine, so I can't easily check this out right now. -- Steve Alexander Software Engineer Cat-Box limited
participants (5)
-
Bill Anderson -
cs＠comlounge.net -
Phillip J. Eby -
Steve Alexander -
Steve Spicklemire