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

[Martin Aspeli]

Andreas Jung wrote:
> 
> --On 28. Februar 2008 20:35:09 +0100 Dieter Maurer <dieter at handshake.de> 
> wrote:
> 
>> 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?
> 
> Huh? Because we're looking for a clean solution and not for a hack!
> Because this solution is extensible. An index can provide the introspection 
> directly or another application could implement the functionality as needed 
> through adaption. Having something hardcoded for each index type within the 
> setuphandlers is a hacker solution. And the setuphandler should ideally not 
> know about index internals.

Respectfully, I'd say that if we can have a hacky solution today that 
doesn't wipe indexes on re-install, then that's very valuable. The set 
of standard index types is well known and doesn't change much.

Of course, we should also provide a way to get an interface or something 
else describing the configuration for introspection purposes. Waiting 
one or two Zope versions for that to get a non-purging GS import handler 
when there's a works-90%-of-the-time solution (falling back on current 
behaviour) would be a shame though.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book