Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <6E513E16-B2B6-4BA9-8603-AA86E716B397@gmail.com>
References: <CDD979FA-DB65-42D3-9A4D-8DDC505FD797@ez.no>
 <6E513E16-B2B6-4BA9-8603-AA86E716B397@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <22F8B71E-EC24-4156-A3CD-24C0E17F4915@ez.no>
Content-Transfer-Encoding: 7bit
From: Nicolas Pastorino <nfrp@ez.no>
Subject: Re: QueryElevationComponent : hot update of elevate.xml
Date: Wed, 6 May 2009 14:52:21 +0200
To: solr-user@lucene.apache.org

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