On Mon, Mar 26, 2012 at 2:12 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Sat, Mar 24, 2012 at 3:12 PM, Lukas Kahwe Smith <[email protected]> > wrote: >> More over (optionally) leveraging these has several other advantages: > > Agreed, I think it would be great to have first-class integration from > Oak to *both* Solr and ElasticSearch. As soon as we have a first draft > to the indexing extension points (as described in the other thread) > I'd love to see some prototypes on how they'd work in terms of > external search indexes. Volunteers for that? > >> Now I mentioned facetting [4] above. Right now Jackrabbit does not even >> support COUNT() [5], which I find very painful and a major oversight. But >> really what people have come to expect from full text search is facetting. > > Totally agreed. We need to make sure that the Oak query API supports > faceting and other related query features. The actual implementation > can (should?) be left to individual index components. > >> 3) "cleaner" data in results > > This goes into the discussion of what the query result abstraction in > the Oak API should look like. Breaking the requirement that all query > results be directly linked to nodes in the repository should go a long > way here, but it also opens up the issue of how such results relate > with access controls. We need to put some thought into this...
Access controls is indeed important, and difficult. Ard
