Consistent index handling

This is already the case, at least for the watchdog main collection (subcollections are not indexed).

Can you be more specific about which indexes are not created that way ?

The problem is, indexes are not kept when a collection is dropped, which is the fastest way to empty it: watchdog component, for instance, uses an ensureIndexes() function which is invoked in various install-related circumstances, but other modules may need to do it during production, and will need to rebuild the collection and the index after a drop.

What I've been thinking for some times is that we should probably define some sort of hook_mongodb_schema() in modules using mongodb, containing basically a set partially intersecting the the set of information available in hook_schema() implementations: this would allow a fast truncation maintaining indexes as: (1) drop the collection (2) reapply index(es) from the schema. This would usually be much faster (since it uses a drop) and safer to use (since it would be a one-call, not a sequence) than either a normal drop with app code index re-creation or a $collection->remove(). Such a "schema" would contain:

- name of fixed-name collections
- wildcard or generator for variable_name collections (like the watchdog_event_(MongoId)
- list of indexes
- a mechanism to obtain these with one single call: currently mongodb modules typically use mongodb_collectionname(variable_get(some variable, some default)) every time they need to access their collection, to combine the dynamic names (provided by variable_get) and aliasing support (provided by mongodb_collectionname). Like mondogodb_collectionname(variable_get('mongodb_watchdog', 'watchdog') . '_event_' . $objectId) It might be better (simpler, more resilient) on various counts to use something like mongodb_collection('mongodb_watchdog', 'event', $objectid) for the dynamic (event in watchdog) collections and mongodb_collection('mongodb_watchdog', 'watchdog') for a base collection.

Going one step further would be a direct Views integration made possible either fast, but limited, from such a schema also defining elements, or slow by real-time by reflection on the collections (obtaining the list of fields live in the UI). I think MongoDB (which I haven't looked into) contains something like this already.

So this should be set to Closed (won't fix) and a new issue should be set up for direct Views integration?