On Mon, Mar 26, 2012 at 3:06 PM, Thomas Mueller <[email protected]> wrote: > Hi, > >>>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. > > 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. Agreed > >>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 www.onehippo.com
