lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Pastorino <>
Subject Re: QueryElevationComponent : hot update of elevate.xml
Date Wed, 06 May 2009 12:52:21 GMT

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:
> 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 : 
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.
eZ Systems

View raw message