On Friday, December 6, 2013, Alex Parvulescu wrote: > if we are being technical :) > > the property index already has all the info you'd need, just list all the > keys and you get the facets (not so easy for item counts for one facet > though).
Do IIUC? The facet support[1] in the Solr Api is not exposed except by going direct to the Solr Api? Best regards Ian 1. http://wiki.apache.org/solr/SolrFacetingOverview > > > > > On Fri, Dec 6, 2013 at 4:58 PM, Tommaso Teofili > <[email protected] <javascript:;>>wrote: > > > 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 differ
