[Zope-CMF] Re: What is the status of GS wiping catalog indexes on catalog.xml import?

[greenman]

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 <wich... at wiggy.net> 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 <wich... at wiggy.net>    It is simple to make things.http://www.wiggy.net/                  It is hard to make things simple.
> _______________________________________________
> Zope-CMF maillist  -  Zope-... at lists.zope.orghttp://mail.zope.org/mailman/listinfo/zope-cmf
>
> Seehttp://collector.zope.org/CMFfor bug reports and feature requests