Hi,
On Apr 10, 2009, at 16:51 , Ryan McKinley wrote:
On Apr 10, 2009, at 7:48 AM, Nicolas Pastorino wrote:
Hello !
Browsing the mailing-list's archives did not help me find the
answer, hence the question asked directly here.
Some context first :
Integrating Solr with a CMS ( eZ Publish ), we chose to support
Elevation. The idea is to be able to 'elevate' any object from the
CMS. This can be achieved through eZ Publish's back office, with a
dedicated Elevate administration GUI, the configuration is stored
in the CMS temporarily, and then synchronized frequently and/or on
demand onto Solr. This synchronisation is currently done as follows :
1. Generate the elevate.xml based on the stored configuration
2. Replace elevate.xml in Solr's dataDir
3. Commit. It appears that when having elevate.xml in Solr's
dataDir, and solely in this case, commiting triggers a reload of
elevate.xml. This does not happen when elevate.xml is stored in
Solr's conf dir.
This method has one main issue though : eZ Publish needs to have
access to the same filesystem as the one on which Solr's dataDir
is stored. This is not always the case when the CMS is clustered
for instance --> show stopper :(
Hence the following idea / RFC :
How about extending the Query Elevation system with the
possibility to push an updated elevate.xml file/XML through HTTP ?
This would update the file where it is actually located, and
trigger a reload of the configuration.
Not being very knowledgeable about Solr's API ( yet ! ), i cannot
figure out whether this would be possible, how this would be
achievable ( which type of plugin for instance ) or even be valid ?
Perhaps look at implementing custom RequestHandler:
http://wiki.apache.org/solr/SolrRequestHandler
maybe it could POST the new elevate.xm and then save it to the
right place and call commit...
Thanks Ryan for your answer.
Here is the related issue in JIRA : https://issues.apache.org/jira/
browse/SOLR-1147
It includes a Request Handler, as you advised, which takes care of
all this. I guess we can follow up on this on JIRA from now on.
--
Nicolas
eZ Systems
