Recently, there was a question on the mailing list asking about debugging a secondary index (to make sure it had the expected values in it). @danielmewes responded with this generally helpful technique:
secondary index debugging
An easy way to check which keys will be inserted into a secondary index is by running a .map(secondaryIndexFunction.default(null)) on the table. If you want to create a multi index, you can replace the map by concatMap.
Assuming that you want to create a multi index so that you can look up messages by the IDs of their responses (in JS):
r.table(...).indexCreate("resp_ids", function(x) { return x('response')('messages')('message-id'); }, {multi: true} )
other techniques
turn a .filter into a .map to see what's being matched
using r.expr to create dummy data without needing to create a table to test a query on
@neumino and @AtnNn both have a huge bag of reql tricks, some of which I bet are good for debugging
Recently, there was a question on the mailing list asking about debugging a secondary index (to make sure it had the expected values in it). @danielmewes responded with this generally helpful technique:
secondary index debugging
An easy way to check which keys will be inserted into a secondary index is by running a
.map(secondaryIndexFunction.default(null))
on the table. If you want to create a multi index, you can replace themap
byconcatMap
.Assuming that you want to create a multi index so that you can look up messages by the IDs of their responses (in JS):
r.table(...).indexCreate("resp_ids", function(x) { return x('response')('messages')('message-id'); }, {multi: true} )
other techniques
.filter
into a.map
to see what's being matchedr.expr
to create dummy data without needing to create a table to test a query on@neumino and @AtnNn both have a huge bag of reql tricks, some of which I bet are good for debugging