Changing options in a core part does not trigger a re-evaluation of the solr-instance recipe

[fxt]

If you have a multi-core configuration with one buildout part for the solr-instance recipe and other parts for the options to be used with each core, you have a solr-instance part that does not correctly recognize its dependency on the options specified in the core parts. If you change an option in one of the core parts and run buildout, the solr-instance recipe will not recreate the solrconfig.xml and schema.xml files (actually, it will not run its installation code at all). The init method of the MultiCoreRecipe class should modify the options dictionary that its is passed in to let the buildout know whether or not anything has changed and whether buildout should call the install method on the MultiCoreRecipe object. When you change an option in one of the core parts of the configuration file, the MultiCoreRecipe gets access to them through the parameters that buildout passes it, but it fails to return (through the options parameter) enough state to allow buildout to recognize that something has changed since the last install.

[davidjb]

Yep, I've seen this issue happening as well. What's the recommended way of handling something like this? As you've mentioned, we have to modify the options parameter. What's a good strategy for this:

• iterate through and transpose each of the 'core' options into this parameter?
• obtain something like a checksum or hash of the 'core' options and store that?
• ...something else?

Are there any other recipes that have/have solved the same issue? Unsure what would be 'best practice'.

[fxt]

If you look at the buildout source code (in buildout.py under the comment " # uninstall parts that are no-longer used or who's configs

have changed")

you'll see that the options dictionary you return from the constructor of your recipe class is compared to the old options dictionary using the == operator. To me that means that you could just add the "core" options to the options "returned" by the MultiCoreRecipe constructor; e.g. options['core1'] = buildout['core1'].copy(), options['core2'] = buildout['core2'].copy(), something like that.

Mind you, though, I have not written any recipes myself; I have just looked at the source code of buildout and some of the recipes I have been having problems with :-)

On Sun, Sep 1, 2013 at 9:10 PM, David Beitey notifications@github.comwrote:

Yep, I've seen this issue happening as well. What's the recommended way of handling something like this? As you've mentioned, we have to modify the options parameter. What's a good strategy for this:

• iterate through and transpose each of the 'core' options into this parameter?
• obtain something like a checksum or hash of the 'core' options and store that?
• ...something else?

Are there any other recipes that have/have solved the same issue? Unsure what would be 'best practice'.

— Reply to this email directly or view it on GitHubhttps://github.com/collective/collective.recipe.solrinstance/issues/24#issuecomment-23636953 .

[davidjb]

This should fix it. Due to the way buildout maintains the options, I've converted the other core's settings structure into a string and stored accordingly. Essentially the same thing, just that it's serialisable. When Buildout runs again, this gets updated and thus tracked. https://pypi.python.org/pypi/collective.recipe.solrinstance/5.1 is out now.