Feature dependencies chains

Feature dependencies chains:
I wanted to improve the RavenDB query optimizer, so it can merge similar indexes into a single index.
It is actually fairly simple to do (conceptually). But that leaves us with the problem of what to do with the indexes that we just superseded.
The whole point here is to reduce the number of indexes, not to create an index that will never be used.
So the next step was to make sure that we can cleanup unused auto indexes. That is great…
Except that we don’t have any way of tracking unused indexes, so before we could do that, we have to add tracking for query times.
Okay, let us do that.
Wait, we don’t have a place to put those in, and anyway, we don’t want to save it all the time, that would mean IO for every query, and what about concurrent queries?
So we need to add a way to save this, and make sure that there is some batching going on in there, so we won’t go to the disk all the time. And wait, there is this other feature over there that needs something similar, so we might as well solve both problems at once…
Okay, let us add that.
Now, where were we again?
That annoying thing about this? You only realize that those are actually problems when you run some deep analysis on the actual feature request. And usually you have to have multiple cycles to get it all out.
It is also very easy to go down one branch, all the way to the bottom, then go up to another branch, which was opened up because of the work you just did. Make for a good workday, but make it harder to predict what you are going to do today.


DIGITAL JUICE