On Mon, Mar 26, 2012 at 2:24 PM, Ard Schrijvers <[email protected]> wrote: > On Mon, Mar 26, 2012 at 1:59 PM, Thomas Mueller <[email protected]> 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. >
