jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: full text search improvements
Date Mon, 26 Mar 2012 13:54:14 GMT

>What our customers also want, is to be able to query on what a
>document for the end-user (customer) is : Some customers have the
>author of a document being some 'author node' referenced by the
>'document node' : Now, by the author's name, you do not find the
>document, because the authors name is stored somewhere else.

This sounds like a join to me, like:

    select * from document d inner join author a on a.id = d.authorId

I would expect the JCR SQL-2 query to look similar.

>Are there plans to also have some ocm mapping for jr3?

Not directly, that is, not within oak-jcr, oak-core, and oak-mk.

> It might make
>sense, to be able to create external indexes by annotating ocm beans

I don't think oak-core should depend on OCM. But your index implementation
(should we call it "query index"?) could use OCM, and the query engine
could be configured to use your index implementation.

>Indexes can be a bit out of sync, when some reference node changes
>(think about a changing author name), but imo acceptable for full text

Yes, I think fulltext search doesn't need to be real-time.

>We exposed it over virtual layers, but, during
>the past years, performance and memory wise, I've switched my opinion
>that I'd rather opt for not having faceted navigation exposed as
>virtual nodes. 

Are virtual nodes a performance / memory problem? I don't see why this
should be the case for Oak. But if it turns out that regular nodes are
simpler, then maybe you should create regular nodes... Those could be
maintained by your index implementation. For example, one node for each
"fulltext search term".


View raw message