jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Asynchronous indexing consistency
Date Wed, 29 May 2013 14:26:50 GMT
Hi,

>For example during large batch imports or content
>migrations it might be useful to be able to speed things up by
>disabling things like full text indexing.

OK, it's good to have a concrete use case.

For a migration, the easiest solution might be to re-create the index at
the end. For a large import to an already large repository that might not
be good enough; but I wonder how common that would be.

>Or it could be that an
>external index server like Solr is down for maintenance or other
>reasons.

That's also a good use case.

> Such cases would obviously lead to some loss of
>functionality, but probably wouldn't be too troublesome if the
>relevant indexers were able to automatically pick up from where they
>left.

Yes, that's true. Specially because you can't typically predict how long
the outage would be (not because of Solr - it might be a hardware failure
or so).

>>It sounds like reading with old revisions.
>
>Not really; let me rephrase. What I'm suggesting is something like this:

Yes, I understand that you have used the "copy" operation to pin an old
revision. That's nice because it doesn't need a new API; it can be
implemented using the already existing copy operation.

What I meant by "reading old revisions" is that we need a way to read old
revisions. You have suggested to use the copy operation to do that, which
is fine; another solution is to not garbage collect a certain revision;
this would require a new API (a way to define which revision to keep), and
the node state API would need to be extended to support using revisions
explicitly.

I think using the copy operation would be preferable, if we find a simple
way to support it in the MongoMK. Possibly the MongoMK could internally
implement the copy operation (when copying a large tree) as keeping a
pointer to a revision. That way we don't need a new API. It would slightly
complicate the MongoMK, specially if we need a way to change the copy.
Just supporting a fast read-only copy (a snapshot) should be feasible I
think.

Regards,
Thomas


Mime
View raw message