Scripted Index Results (I wish it would have a better name) is a really interesting new feature in RavenDB 2.5. As the name implies, it allows you to attach scripts to indexes. Those scripts can operate on the results of the indexing.

Sounds boring, right? But the options that is opens are nothing but. Using Scripted Index Results you can get recursive map/reduce indexes, for example. But we won’t be doing that today. Instead, I’ll show how you can enhance entities with additional information from other sources.

Our sample database is Northwind, and we have defined the following index to get some statistics about our customers:

And we can query it like this:

However, what we want to do is to be able to embed those values inside the company document, so we won’t have to query for it separately. Here is how we can use the new Scripted Index Results bundle to do this:

Once we have defined that, whenever the index is done, it will run these scripts, and that, in turns, means that this is what our dear ALFKI looks like:

Companies doc gets updated, the relevant indexes gets run.
You cannot modify a document that will be indexed by the same index that trigger this operation. The reason for that is to avoid infinite recursion.

Do you and the team have any ideas on how to prevent someone from shooting themselves in the foot, or is that just accepted as collateral damage?

It seems like an issue that could be common across a development team. Two developers could be working on separate but related features on separate branches, where the issue would manifest after the two features were merged into the same branch.

I am just thinking out loud, but what if during the indexing process you also tracked the source of what caused that indexing to happen?

External Document Put

Internal Document Put (script) with Source

You could do pattern matching based on Index, Source, Document Id that caused the index, and frequency within a certain time. If you hit a threshold, you can log a warning in the Management Studio. In addition, you could stop the indexes to save the system.

"Woah we sure touched this one document a lot within a certain time, and it seems what is affecting it is internal to RavenDB, we think there might be something wrong with these indexes: {Index}, {Source}."

You don't have to save this data for a long period of time, you just need a buffered window according to your frequency window (1 minute)? If an item falls out of the window, just throw away that info. Funny enough I think this is a good use case for your previous idea of an event stream.

Khalid,
And now you need to track a WHOLE lot of information in the system.
Not only that, but you need to track the source of each write, and it is pretty expensive and hard to do.
For something that is purely theoretical right now.

Also, there might be valid reasons why you would want to do that (if you know that you do recursion only to a certain level, for example).