jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Question: In Repository Index file.
Date Fri, 06 Dec 2013 22:27:42 GMT
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
> <tommaso.teofili@gmail.com <javascript:;>>wrote:
>
> > Hi,
> >
> > 2013/12/6 Ian Boston <ieb@tfd.co.uk>
> >
> > > 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 <tommaso.teofili@gmail.com>
> > > wrote:
> > > > 2013/12/6 Alex Parvulescu <alex.parvulescu@gmail.com>
> > > >
> > > >> Hi,
> > > >>
> > > >> On Fri, Dec 6, 2013 at 11:06 AM, Jukka Zitting <
> > jukka.zitting@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > On Fri, Dec 6, 2013 at 1:25 AM, Ian Boston <ieb@tfd.co.uk>
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message