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
