Thank you @AtnNn !

That's a good idea. In NoBrainer, I'm planning to store the index definitions in a separate table so that I can check if index definitions have changed. I'd much rather populate that "source" thing.

👍

This will become pretty easy once we have #3636

Just needed this again when debugging something that a user ran into.
It turns out @Tryneus had actually already implemented a print_source() method on func_t, so I just went ahead and hooked that into index_status().

The output isn't perfect, but I think it's worth shipping this even if we later redo it in a nicer way. Sorry for not adhering to the ReQL_proposal standards, but I think the absence of this feature is sufficiently annoying for debugging that we should just ship it.

The indexStatus() output looks like this (note the new source field):

{
    "function": <binary, 127 bytes, "24 72 65 71 6c 5f..."> ,
    "geo": false ,
    "index": "parent_folder_id" ,
    "multi": false ,
    "outdated": true ,
    "ready": true ,
    "source": 'function (captures = [(no implicit)]) (args = [1]) var1("data")("parent_folder_id")'
}

In CR 3288. It's just a two-line addition.

We decided to redo this a bit and actually generate the JS query that you can use to re-create the index (and call the field "query").

Merged into next with the following format:

r.table('t1').indexStatus().pluck("query")
[
    {
        "query": "indexCreate('a', function(_var19) { return _var19.getField("a"); })" 
    } ,
    {
        "query": "indexCreate('b', function(_var19) { return _var19.getField("b"); }, {geo: true})" 
    } ,
    {
        "query": "indexCreate('c', function(_var19) { return _var19.getField("c"); }, {multi: true, geo: true})" 
    } ,
    {
        "query": "indexCreate('d', function(var24) { return r.expr([var24("a"), var24("b").count()]); })" 
    }
]