Hi, Thanks all for the clarification. Good to know there is fallback. If the Solr index is intended for full text, can it still be used to build facets on a reasonably well defined set of properties ?
Best Regards Ian On 6 December 2013 16:20, Tommaso Teofili <[email protected]> wrote: > 2013/12/6 Alex Parvulescu <[email protected]> > >> Hi, >> >> On Fri, Dec 6, 2013 at 11:06 AM, Jukka Zitting <[email protected] >> >wrote: >> >> > Hi, >> > >> > On Fri, Dec 6, 2013 at 1:25 AM, Ian Boston <[email protected]> wrote: >> > > In Oak when a index is stored in the repository, how is it updated >> > > when the repository is MongoDB backed and there are multiple JVM >> > > processes connected to the MongoDB ? >> > >> > That depends on the index and MK implementations. For example the >> > PropertyIndex uses an index structure that can be updated concurrently >> > when the updates affect different areas of the content repository. >> > When using the MongoMK backend concurrent updates to the same nodes >> > will automatically be synchronized, and with the SegmentMK (which also >> > can be used with MongoDB) all commits against the same journal are >> > synchronized. In both cases concurrent updates will automatically get >> > resolved. >> > >> > > Also if using SolrCloud as a search index, is it possible to fallback >> > > to an internal repository stored index if the the SolrCloud index >> > > becomes unavailable ? >> > >> > Yes. The query engine will automatically pick the best available index >> > for each query execution. If a particular index is not available, then >> > the second-best match for those queries that would have used it would >> > automatically get picked. >> > >> >> >> There is one minor nitpick with this statement. >> >> So far we've assumed that the solr index will be used for full-text queries >> only. the only fallback you could use if the solr index becomes unavailable >> is the lucene one, but as far as I know we've said that you would usually >> use one _or_ the other. >> Areas of concern are: the full-text indexing settings may differ, and the >> cost output may need to be tricked into treating the local lucene index as >> a fallback and not a competing full-text index. >> But this is definitely doable. >> > > good point Alex, and probably we may have to write some tests for the cost > comparison for different queries with one or more running indexes to > eventually tune the cost evaluation to work properly in the different > setups. > > Tommaso > > >> >> >> >> > >> > BR, >> > >> > Jukka Zitting >> > >>
