On Mon, Nov 29, 2010 at 2:12 PM, Alexander Klimetschek <[email protected]> wrote: > On 29.11.10 13:25, "Thomas Mueller" <[email protected]> wrote: >>>>the single-big index for the >>>> entire repository that is mandated by the JCR spec. >> >>Sorry, where in the spec is this mandated?
Of course it is not mandated as such, but, the mandated behaviour makes the indexing very inefficient (at least, the default where you do not configure some custom indexing). As a matter of fact, jackrabbit consists of *many* smaller and bigger indexes, but as the emergent behaviour, it could be considered as a single one (one multiIndexReader). For example mandatad behaviour according spec: //*...@jcr:contains(.,'jcr')] must return *all* nodes in the current workspace that contain jcr. This effectively mandates that the entire thing can be searched as a 'single' index. //*...@myproject:title='foo'] order by @myproject:summary This mandates that title and summary *must* be stored Lucene values: This makes a Lucene index very big. > > Not sure if it is actually mandated, but applications expect it and you > might get conflicts with multiple applications. Exactly. > > If one application does not want a certain property to be indexed (because > it does not want to find it in e.g. full text search), there might be > another one who needs it, so you can't configure the right index if you > only have a single one. I would like to opt for an option 'simpleIndex' which just indexes the things that 1) Are efficient to query 2) Are not blowing up the index in size My current implementation I can always avoid the complex queries Ard > > Regards, > Alex > > -- > Alexander Klimetschek > Developer // Adobe (Day) // Berlin - Basel > > > > > -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada • Montréal 5369 Boulevard St-Laurent • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • [email protected]
