Hi, 2013/12/6 Ian Boston <[email protected]>
> 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 ? > technically speaking of course, we may also support facets for the Lucene index [1]. What I wonder is if / how we could expose them on the JCR API level. Any idea? Regards, Tommaso [1] : http://lucene.apache.org/core/4_0_0/facet/org/apache/lucene/facet/doc-files/userguide.html > > 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 > >> > > >> >
