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

[Dieter Maurer]

Andreas Jung wrote at 2008-2-28 07:13 +0100:
>--On 27. Februar 2008 21:59:58 +0000 Maurits van Rees 
><m.van.rees at zestsoftware.nl> wrote:
>
>> greenman, on 2008-02-27:
>>> 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.
>>
>> The problem is that GenericSetup does not know if your current index
>> is of the same type and has the same settings/properties as the index
>> that you specify in catalog.xml.  Apparently it is hard/impossible to
>> reliably compare the existing and the wanted index.  So GenericSetup
>> has no choice but to remove the existing index and make a new one.
>>
>>
>
>How about the following idea:
>
> - within the Zope core we define an _optional_ interface for indexes -
>   something like:
>
>      class IIndexConfiguration(Interface):
>
>          def getConfiguration():
>              """ Returns a dict with index specific configuration
>                  parameters.
>              """
>
> - on the CMF/GS side we could register adapter for each index type
>   we know (basically the Zope 2 core indexes, ExtendedPathIndex,
>   TextIndexNG 3) and retrieve the related information

I do not understand why something like this should be necessary.

When the export handler is able to extract all relevant configuration
parameters for an index, why should the import handler
not be able to check the configuration parameters in a profile
against an existing index and determine that it needs to do nothing?



-- 
Dieter