MongoQueryIndexes
The query indexes of an aggregate type's snapshot collection:
owner_ix: {tenant_id: 1, owner_id: 1}, partialFilterExpression: {deleted: false}
space_ix: {tenant_id: 1, space_id: 1}, partialFilterExpression: {deleted: false}
<name>: {tenant_id: 1, <key>: 1, ..., _id: 1}, partialFilterExpression: {deleted: false} (each x-wow-index entry)Every index leads with the tenant, which admission adds to every query, and is partial on the snapshots that are not deleted, its default scope: a query whose filter holds deleted: false can use it. A key is the document path the filter, sort and aggregation compilers read for it (MongoSnapshotDocuments), so the planner matches the two. A declared index ends with the tie-breakers every snapshot sort ends with (MongoSnapshotDocuments.tieBreakers, _id), so a sort by its keys under the tenant's equality whose tie-breaker runs in the same direction is the index's order, forward or backward, with no sort stage: every sort ends with the tie-breaker in the direction of its last field (me.ahoo.wow.query.backend.tieBreakerDirection): a sort by the keys in one direction is read in index order. An existing index of another shape is drift, as any other (manage).
MongoDB names indexes per collection, so a declared index keeps its own name. The store creates the two scope indexes with the collection; planning them here lets validate report them too.
Functions
The indexes of plan, the access attributes of aggregate in context, on its log collection: led by the tenant, each attribute's document path (multikey for a multiple one), partial on the streams ({version: {$exists: true}}), which every events query asks for, so it can use them; the log's placeholders hold no version. No tie-breaker ends them: they narrow the streams an access policy lets a reader see, and are not read for an order, which for an events query ends with the stream key (tenant, aggregate, version).