[Framework-Team] Re: PLIP125 (link integrity) part II - redirect-on-move ready for merge

Martin Aspeli optilude at gmx.net
Sun Dec 24 01:27:02 UTC 2006

Hi Hanno,

 >> For the record, I love this functionality :)
 > While I like this too, I'm a bit concerned about the performance
 > penalty. Is there an easy way to turn this behavior off? Like a switch
 > in some control panel?

There is not, but there easily could be. The hardest part is making the 
control panel page. :)

I don't think it's that much of a hit, though. On every object move or 
delete, the following operations take place:


They basically look up and perform an operation on the storage utility in:


Those operations are string manipulation and BTree lookups/inserts. I 
doubt they would cost much relative to the cost of renaming, cut/pasting 
or deleting an object in general. I'd be tempted to wait to make a 
switch until we have some evidence that it's a problem, but having those 
two event handlers short-circuit on some switch somewhere would be trivial.

The other performance hit (which is bigger) is on the 
default_error_message page when it gets a NotFound error. In that case, 
we attempt to do a redirect (more string and btree logic), and possibly 
perform some traversal and catalog searches, in the first three methods 
in this view:


I don't see why the 404 page needs to be fast, though (except during the 
spam attack we had on plone.org, but that's rather different).

 >> I'd like to merge this now, unless people have objections. There's no
 >> bundle, but the code is here:
 >> http://dev.plone.org/plone/browser/plone.app.redirector/trunk
 >> http://dev.plone.org/plone/browser/CMFPlone/branches/plip125-redirector
 > The only thing that seems a bit dubious to me is the IGNORE_IDS constant
 > in browser.py. I think this is a policy decision that should be easier
 > to customize. The simplest solution here would be to turn this into a
 > simple global utility with just one method that would return this list.
 > This way people who really wanted to customize it could add their own
 > local utility to return something different (for instance ignore all
 > aliases registered on any content type + all dynamic view templates + 

Good idea. I'd forgotten about that whart, actually, it was originally 
taken from the (age-old) RedirectionTool.

 > Is there any way to clean up some old redirects, like a 'delete all
 > redirects' option somewhere? I imagine that people might need this after
 > a while.

Not for now. The operations are there, it just requires some UI. I'm not 
100% convinced its needed, but I agree that it feels like something that 
may need it one day (note that redirects are cleaned up when objects are 
deleted, so in theory only redirects to actual, live objects should 
exist, and of course, redirects are only created when an object is 
actually renamed or cut/pasted (moved), which in itself is not something 
you'd expect to happen with extreme frequency).


More information about the Framework-Team mailing list