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 i
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, he
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.
>
>
With OAK-1980 ordered indexes should be able to be delivered under
specific paths.
Hi,
On Tue, Aug 26, 2014 at 10:01 AM, Davide Giannella 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 called
>> "k
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
> /co
Hi,
Did we already run into this problem in reality? How much of a pain point
is it? I think creating indexes is a "maintenance job", which doesn't need
to be done very often, comparable to creating a backup. If creating the
index is asynchronous, then it's OK if it's slow. Re-indexing (re-buildin
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
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
/content/bar/two@keywords=
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 wrote:
> Hello team,
>
> when we issue the reindex by changing the index definition with
> `reindex=true` the algorithm scan all the repository and issue
Hello team,
when we issue the reindex by changing the index definition with
`reindex=true` the algorithm scan all the repository and issue the "node
modified/added" to the specified index.
While this works with small repositories it doesn't really scale with
big ones.
So for taking an extreme ex
10 matches
Mail list logo
