Conversation
The reindexer operates on a fixed list of indexes. I'm not certain if we have a compelling use case to expose a generalized config for this, but in the meantime, we have pro features which would benefit from periodic re-indexing. Add a pilot hook that allows for extra reindex targets while preserving the existing schedule and timeout behavior. The reindexer also filters configured targets through `IndexesExist` so missing optional indexes are skipped cleanly, and tests pin the default, merged, and deduplicated target lists.
|
@brandur actually what's your thought on whether this should just be part of |
So if the user specifies their own set of indexes to reindex and then uses Pro, Pro would append one list to the other? I guess this should be fine. The only the downside I can imagine is if you people end up coming to rely on it too much, they may request additional customization like number of concurrent reindexes, etc., and before you know it you could a more expansive set of options needed (we already have two on there just for the reindexer and hopefully it wouldn't expand anymore than that). I suppose that's not the end of the world though. It'd be sort of nice to have a way of marking a property as "contemplative, but not totally stable" in Go to give us a little leeway to change this sort of thing, but I don't think it's possible. |
The reindexer operates on a fixed list of indexes. I'm not certain if we have a compelling use case to expose a generalized config for this, but in the meantime, we have pro features which would benefit from periodic re-indexing.
Add a pilot hook that allows for extra reindex targets while preserving the existing schedule and timeout behavior. The reindexer also filters configured targets through
IndexesExistso missing optional indexes are skipped cleanly, and tests pin the default and merged target lists.