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:24:39 GMT
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
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.

Regards Ard

>
> Regards,
> Thomas
>



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

Mime
View raw message