ArangoDB: no index support — all `indexed query` results are N/A

[tobiemh]

Summary

The ArangoDB adapter does not implement build_index, so it inherits the trait default which returns NOT_SUPPORTED. As a result, every "indexed query" result for ArangoDB is N/A — ArangoDB is never benchmarked with an index on any scan. Its indexed column is absent, which can be misread as a failure rather than "not implemented."

Where

arangodb.rs defines no build_index / drop_index, so it falls back to the engine default:

// src/engine.rs:250
fn build_index(&self, _spec: &Index, _name: &str) -> impl Future<Output = Result<()>> + Send {
    async { bail!(NOT_SUPPORTED_ERROR) }
}

When BuildIndex returns None, the harness still emits an indexed row but renders the cell as - / N/A:

// src/benchmark.rs:541 (comment)
// Still emit indexed rows so CSV/HTML rows align; cells show "-" when result is None

So on where_field_many_contains_string_order_by_desc (and every other indexed scan) ArangoDB shows a full-table-scan number and N/A for indexed.

Proposed fix

Implement build_index / drop_index for ArangoDB so it participates in the indexed-scan comparison:

• Scalar / compound fields (e.g. http_status, created_at): a persistent index via ensureIndex({ type: "persistent", fields: [...] }).
• Array-element fields (the Surreal tags.* spec): ArangoDB supports indexing array elements with the field[*] syntax in a persistent index (e.g. tags[*]), so translate tags.* → tags[*].
• Full-text (index_type = "fulltext"): ArangoDB inverted index / ArangoSearch view, or mark explicitly unsupported.

If a given index shape genuinely isn't supported, prefer an explicit, documented skip over a silent NOT_SUPPORTED, so the comparison page distinguishes "unsupported" from "untested."

Impact

Until this is implemented, any chart comparing "indexed query" performance that includes ArangoDB is incomplete — ArangoDB simply has no indexed data point.