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...
ryan
