As a user of such an index, I do expect the index to properly update itself. Adding configuration to make that "faster" at the cost of index correctness doesn't help.
If the index works asynchronously and might take some time to be up to date, we need to clearly document this. And first check if that's ok. AFAIR, with Jackrabbit 2 we guaranteed immediate index update upon session.save() for everything but fulltext which might take longer due to text extraction. This is ok since all "programmatic queries" that might have the requirement to work correctly immediately after content changes would be unlikely to include a fuzzy fulltext search (jcr:contains), as opposed to end user searches on a website for example. Cheers, Alex On 27.08.2014, at 05:54, Davide Giannella <dav...@apache.org> wrote: > On 26/08/2014 15:10, Justin Edelson wrote: >> ... >> In this case, I think Thomas's suggestion makes much more sense. Let's >> just add a property to the QID which allows an index to be restricted >> to particular paths. >> > As said previously there was something in my idea that was not > convincing me, hence I started the discussion here :) > > After this discussion I'm as well for keeping the reindex as it is. We > could in case enhance it, if not already, to make sure that if an index > definition is under a specific path, only that path is traversed rather > than the whole repo. As said: if not already. > > Nevertheless we have some use cases where we could need a workaround > like it and I thought of a groovy script to be used in the oak-console. > > This script will receive in input a list of paths to parse and will > reindex only those. We could have cases where an index is defined as > root level but the end user knows that at the current stage it's > actually used only by part of the content tree. > > In this way it won't be part of the core but a util that someone can use > as not. > > Thoughts? > > Regards > Davide > >
