fq=fieldMapper.getDocumentDomainField()+":"+getId()
to all queries. This feature can be activated by setting the {@link #MULTI_YARD_INDEX_LAYOUT} in the configuration. However this requires, thatthe documents in the index are already marked with the ID of the Yard. So setting this property makes usually only sense when the Solr index do not contain any data. Also note, that the different Yards using the same index MUST NOT store Representations with the same ID. If that happens, that the Yard writing the Representation last will win and the Representation will be deleted for the other Yard!
The SolrJ library is used for the communication with the SolrServer.
TODO: There is still some refactoring needed, because a lot of the code within this bundle is more generic and usable regardless what kind of "document based" store is used. Currently the Solr specific stuff is in the impl and the default packages. All the other classes are intended to be generally useful. However there might be still some unwanted dependencies.
TODO: It would be possible to support for multi cores (see http://wiki.apache.org/solr/CoreAdmin for more Information)
However it is not possible to create cores on the fly (at least not directly; one would need to create first the needed directories and than call CREATE via the CoreAdmin). As soon as Solr is directly started via OSGI and we do know the Solr home, than it would be possible to implement "on the fly" generation of new cores. this would also allow a configuration where - as default - a new core is created automatically on the integrated Solr Server for any configured SolrYard.
@author Rupert Westenthaler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|