jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ard Schrijvers <a.schrijv...@onehippo.com>
Subject Re: Re (OAK-36) Implement a query parser - what about indexing?
Date Mon, 26 Mar 2012 12:29:51 GMT
On Mon, Mar 26, 2012 at 2:24 PM, Ard Schrijvers
<a.schrijvers@onehippo.com> wrote:
> On Mon, Mar 26, 2012 at 1:59 PM, Thomas Mueller <mueller@adobe.com> wrote:
>> Hi,
>>
>>>Currently, for Hippo, I am doing something
>>>similar for the query api, that can seamlessly delegate to Solr or
>
> Small correction : I am trying to get it on the agenda to really
> seamlessly integrate with it, as currently we have some projects with
> home-grown integration. I however did a simple 1 day poc some time ago
> which seemed pretty promising.
>
>>>jackrabbit, both returning a jcr node iterator (although the solr
>>>index through solrj can also return plain pojo's).
>>> I really like the
>>>first option (pre-commit example) and third (observation based), and
>>>still see many bears on the road for the second (full-text on
>>>post-commit)
>>
>> Would it make sense to implement this in Oak? Or do you prefer an external
>> project?
>
> You mean the Solr integration? If so, I think in the first place it is
> important that we try to make it simple to integrate with an external
> index. Being able to listen to a commit journal to index nodes like
> Jukka describes would help enormously already (and be able to do this
> in a clustered environment, such that only one single node picks up
> the journal). I am not sure if it can be made generic enough to be

Excuse me, the above might be confusing:

By ' I am not sure if it can be made generic enough' I mean the Solr /
Elastic Search integration, not the part about being able to listen to
the journal.

> part of oak (core). Perhaps an optional module? Also, although I am
> unfamiliar with the project, it might be that elastic search is a
> better match for oak than Solr : I just happen to mention Solr because
> we are planning to seamlessly integrate it into our site building
> stack (although I think they don't have a seamless integration, some
> DMS providers like Alfresco and Nuxeo, which used to be a fork off /
> based on JR in the past, also integrated with Solr lately )
>
>>
>>>I've one more question regarding the oak search/indexes : Will we be
>>>able to query that returns something else than jcr nodes/rows? I
>>>frequently want to be able to get a query result from the repository
>>>that cannot be returned as node iterators. For example query on stats,
>>>or a query for 'auto-completion' on some property (thus return some
>>>part of the TermEnum for example)
>>
>> Could you give a few concrete examples? What would such a query look like,
>> and what kind of data would it return?
>
> For example as Jukka mentions there is faceted navigation which is not
> easy to expose over jcr nodes/rows. Another non faceted example would
> be for auto-suggestion / completion : For example give me all the
> terms for property 'bar' that start with 'fo'  : In this case, you'd
> just like to be able to return a list of terms.
>

Mime
View raw message