Currently, text queries are not allowed on views. However, we should try to let them succeed whenever possible, and the code that looks for text indexes should be views-aware. Because text matches must be the first stage in a pipeline, this can only be allowed if it's safe to let the match float to the front of the pipeline.

When doing this, we should be careful to ensure that this transformation does not leak sensitive information in the view pipeline.

Original Description

We should consider whether or not to add a specific error message that explicitly mentions that $text queries are not supported on views. If a user attempts such an operation, they'll get an IndexNotFound message:

> db.view.find( { "$text": { "$search": "foo" } } )
Error: error: {
        "ok" : 0,
        "errmsg" : "text index required for $text query (no such collection 'test.view')",
        "code" : 27,
        "codeName" : "IndexNotFound"
}

This will always happen, even if the underlying collection on the view does have a text index. (A user might also be confused at the message stating "no such collection 'test.view'", especially if they're given an opaque handle to something that may be either a view or a collection.) The user might then try

> db.view.ensureIndex( { x: "text" } )
{
        "ok" : 0,
        "errmsg" : "Cannot create indexes on a view",
        "code" : 166,
        "codeName" : "CommandNotSupportedOnView"
}

Perhaps it would be easier on the user to simply detect this up-front?