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

[Andreas Jung]

--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.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-cmf/attachments/20080229/f299520e/attachment.bin