Andreas Jung wrote:
--On 28. Februar 2008 20:35:09 +0100 Dieter Maurer <[EMAIL PROTECTED]>
Andreas Jung wrote at 2008-2-28 07:13 +0100:
--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 -
""" Returns a dict with index specific configuration
- 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.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests