I was wondering if there was a simpler solution. The proposal is oriented towards testing current state to the proposed new state for individual indexes. This avoids the need for the profile declarations to assume a present state of the catalog. But looking at other parts of GS - e.g. viewlet managers where you can ask for a hidden flag to be removed, and object node handlers where you can ask for a specific object to be removed with remove="True", then it seems that GS is quite entrenched in creating state transitions that are based on actions for an assumed current state. I guess this is the only way to manage extension profiles which modify parts of state and do not reflect the entire state of the system and which are applied linearly over perhaps a set of profiles.
So, for the catalog.xml importer, why can't the trigger for reindexing an index be a flag on the catalog index declaration itself? Is it really generic setups role to determine if changes to an index invalidate the values it already holds? If you were to change properties of an index through code and not GS, then it would be up to you whether you reindexed all your objects or not. Perhaps the catalog should have an event listener for index invalidate events and accumulate these until code or human causes all invalidated indexes to be reindexed. That way, some catalog API level calls that change certain properties of an index that require reindexing could trigger their own invalidate events without some external code (such as GS) trying to guess whether or not it needs to force a re-index. On Feb 26, 11:16 pm, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > Previously greenman wrote: > > The bug/feature referenced > > herehttps://bugs.launchpad.net/zope-cmf/+bug/161682 > > relates to the wiping of indexes in the ZCatalog when a GS step for > > the catalog is run. > > > I was wondering if there is a targeted release for this fix(feature). > > It has a huge impact on site migrations that require reloading of > > profiles to update configuration states. > > As documented in that issue until the catalog index API is changed and > all indexes have been updated to support the new API that bug is > impossible to fix. So far there do not seem to be any volunteers to do > that. > > Wichert. > > -- > Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make > things.http://www.wiggy.net/ It is hard to make things > simple. > _______________________________________________ > Zope-CMF maillist - [EMAIL > PROTECTED]://mail.zope.org/mailman/listinfo/zope-cmf > > Seehttp://collector.zope.org/CMFfor bug reports and feature requests _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
