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 13:24:37 GMT
On Mon, Mar 26, 2012 at 3:06 PM, Thomas Mueller <mueller@adobe.com> wrote:
> Hi,
>>>Would it make sense to implement this in Oak? Or do you prefer an
>>> 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
> I just think it would be simpler for everybody if we could discuss on the
> concrete source code, instead of communicating only by email about
> abstract ideas. It's just more efficient in my view.

The concrete source code is only available currently as a one day poc
in patch form in jira issue: It is also tightly coupled with
'HippoBean's' , some sort of read only ocm mapping (resembling
jr-ocm). The rest of the the 'non-seamless' efforts (useless for oak)
are closed source customer code

>>Being able to listen to a commit journal to index nodes like
>>Jukka describes would help enormously already
> The current mechanism used for the property index is a MicroKernel wrapper
> implementation. Other solutions are possible of course.
>>I am not sure if it can be made generic enough to be
>>part of oak (core). Perhaps an optional module?
> I think such discussions are more efficient if we talk about the actual
> "source code". As soon as we have the main pieces in place, I suggest we
> write the documentation and an example about how to attach a custom
> indexer module.


>>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.
> How would security work for such cases? Because I currently assumed we can
> reuse the security features that are available for reading normal nodes.

Very good point. Also, faceted navigation, described in the other
search thread, should take security into account when counting : A
node should not be part to the faceted result (for example the count
of some property value occurences) if the user is not allowed to read
the node.

> If security is not required in this case, it might make sense if the
> fulltext search would return "pseudo-nodes" (nodes that are not stored in
> the microkernel, and are not part of access rights checking). Each "term"
> could be such a pseudo-node with a property "term". The problem I see with
> custom Row implementations is that joins between your fulltext
> implementation and regular nodes would not be possible.

Yes, joins are a problem I think. Also ACLs are a problem. I saw Nuxeo
tries to solve it with a separate Solr core [1], but I am not sure
about the scalability of this effort. It also needs the non released
4.0 version of Solr it seems

Regards Ard

[1] https://github.com/nuxeo/nuxeo-solr/tree/master/architecture

> 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

View raw message