Re: sidnei's reindexing improvements

Sidnei da Silva wrote:
> On Fri, Dec 09, 2005 at 03:12:54AM -0800, Rob Miller wrote:
> | these are definitely band-aid measures, and they don't fix the problem 
> | entirely
> 
> Yes they do fix the problems in Archetypes. The rest of the problems
> are in CMF. See thread started by Alec.

i still think they're band-aid measures.  IMO, the idea of a catalog 
multiplexer should live in the CMF, not in AT, and all catalog indexing 
should be handled by this multiplexer.
> 
> | but they do make some improvements.  according to my 
> | calculations, when running the CMFPlone unit tests, sidnei's branch 
> | results in 237 less 'object already unindexed' errors.
> |
> | ultimately, we do want some sort of event driven indexing scheme.
> 
> Because it's cool or because it will solve a problem? Which problem
> will it solve?

i don't care about cool.  right now, the strategy is index immediately, 
whenever it's apparent that a reindex needs to happen.  oh, but maybe 
we've reindexed already.  or maybe another reindex is going to happen. 
so first check to see if those cases are true, and maybe reindex 
immediately, or maybe don't, depending on the results.  nice.

i think a better strategy would be to just flag that reindexing needs to 
happen, so that the encapsulated cataloging code can handle the 
necessary indexing at the transaction boundary.  this changes the 
behaviour a little bit; there may be some cases where an immediate 
reindexing is needed.  these cases are few, however, and the burden of 
immediate indexing should be placed on the code that requires it, not on 
the whole system.

note that Florent has already got this working in CPS.  ultimately, it 
should live in CMF.  i'm not convinced we need ben's proposed messaging 
system to make it happen, but i am convinced that the current strategy 
sucks, and that while your changes do eliminate some redundancy, they 
are just a stopgap measure.

> | i'm particularly not happy about removing some of the indexing from 
> | CatalogMultplex and putting the indexing burden on the manage_after* 
> | methods.
> 
> There's no 'extra' burden. Just what was there before.

right.  but it shouldn't need to be there.  indexing happens there for 
historical reasons, because there wasn't any event system.  now we have 
txn boundary events, we should use them.

> | but for now, there are some wins to be had w/ sidnei's | changes.
> | anyone have objections to this code making it into the AT 1.3 |
> | branch?
> 
> The branch has been merged already.

good.

-r



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click