Yes. That’s what I was trying to get at.
What I had in my mind immediately was a subset case, where there is only a mapping.
N1QL could receive the objects in order based on the index, but would not receive the index itself. It would just need to search based on the index (with start/end probably), and then hand the docs back to the rest of the N1QL query to perform their normal tasks.
Essentially it would work in the same way as just defining an index on e.g. ‘name’. The reason why I see it as being easy to implement is that I assume that the underlying process for using indexes on specific fields probably already does this, so it would just be extending a feature you’ve already implemented.
Having an understanding of the meaning of the index, especially if there’s a reduce, is obviously much harder, but that wasn’t what I was thinking of. In fact I’m not sure how useful N1QL would be with reduce’s. I’m only thinking of the case with maps only.
OK, here’s an example that I think might demonstrate a usage:
Imagine you’ve got a list of people, with name etc, and a list of their experience with the age, like (I’ve left out quotes for speed):
{name:name,experience:[{company:co1,start_date:date,end_date},{…}]
You then create an index on the number of total years’ experience, which you call (originally) yearsExperience.
Then you want to perform some other N1QL queries, but using the ordering of the yearsExperience as the index. I think this would be a valid reason for wanting to access the yearsExperience index, even though it’s not defined in N1QL.
In general, indexes that aren’t directly based on key values, but are calculated from them, could warrant such usage.
Good news about DP4 - looking forward to trying out the new features. What’s the timeline for general availability?
Cheers.