--On 27. Februar 2008 21:59:58 +0000 Maurits van Rees <[EMAIL PROTECTED]> 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
- the related GS asks each index for its configuration and takes
appropriate action based on the comparison of the values from the
profile and the existing index.
Adding the interface to Zope 2.11 or backporting it to Zope 2.10
would not be a problem. Since the Zope 2.11 branch is offically closed for
new features, the index specific implementations of IIndexConfiguration
should be implemented outside the Zope core but we might move the
implementation into the Zope core with Zope 2.12. Sounds reasonable?
Andreas
pgpA8OQK4gGQ3.pgp
Description: PGP signature
_______________________________________________ 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
