lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Pastorino <n...@ez.no>
Subject QueryElevationComponent : hot update of elevate.xml
Date Fri, 10 Apr 2009 11:48:13 GMT
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 ?

Thanks a lot in advance for your thoughts,
-- 
Nicolas




Mime
View raw message