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
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
Hi Davide,
this would be nice indeed! wouldn’t that be “indexPath”, not “re-indexPath” ?
Nicolas
On 26 Aug 2014, at 12:04, Davide Giannella dav...@apache.org wrote:
Hello team,
when we issue the reindex by changing the index definition with
`reindex=true` the algorithm scan all the
Hi Davide,
So what would happen to the already-indexed content which wasn't in
one of the reindexPaths?
For example, let's say I'm building an index of a property called
keywords. In the repo, I have:
/content/foo@keywords=something
/content/bar/one@keywords=something
On 26/08/2014 11:27, Nicolas Peltier wrote:
Hi Davide,
this would be nice indeed! wouldn’t that be “indexPath”, not “re-indexPath” ?
I'd rather keep a sort of namespace in the property naming. By stating
`reindexPath` it should be clear that is only related to reindexing and
that if the index
On 26/08/2014 14:13, Justin Edelson wrote:
Hi Davide,
So what would happen to the already-indexed content which wasn't in
one of the reindexPaths?
For example, let's say I'm building an index of a property called
keywords. In the repo, I have:
/content/foo@keywords=something
Hi,
On Tue, Aug 26, 2014 at 10:01 AM, Davide Giannella dav...@apache.org wrote:
On 26/08/2014 14:13, Justin Edelson wrote:
Hi Davide,
So what would happen to the already-indexed content which wasn't in
one of the reindexPaths?
For example, let's say I'm building an index of a property
