0.13.1

A patch release about one engine being usable. On a MongoDB connection that the deployment
supplied — the seeded, admin-managed kind — this product had been answering as if it were a SQL
database: Find Documents on a collection wrote SELECT * FROM customers LIMIT 50;, the
row menu offered Analyze Table and Vacuum Table, Profile Table failed on every
collection, and the query agent drafted statements the editor could not run.

All of it traced to one request, and everything below was measured against a live MongoDB with
a seeded dataset rather than reasoned about.

One 400 turned MongoDB into a SQL database

A managed connection reaches the browser with its password and connectionString removed —
the server keeps the credentials and resolves the connection by its seed id. MongoDB is
normally configured by connection string alone, so what reached the browser no longer named a
database at all, and the request that asks "what can this engine do?" answered
400 — Host or connection string is required for MongoDB.

Absent capabilities read as SQL everywhere: the query generator, the row labels, the tab
type, the maintenance actions. So a document engine was offered a relational product.

The fix is the rule the rest of the app already followed — send the seed id and let the server
resolve it. Two more places that sent the stripped object are fixed with it (the data profiler
and the monitoring pool panel), where a warm server-side cache had been hiding the same
failure until a restart.

This was not MongoDB-specific. MongoDB was simply the one connection in the shipped
configuration defined by a connection string; any engine configured that way reached the same
dead end.

Profile Table works on MongoDB

It had asked the provider for an operation the provider has never supported, so every
collection answered 400. The test that covered this path accepted the wrong operation name,
which is why it shipped; the test now rejects unknown operations the way the engine does.

The schema tree names the fields inside a document

Field inference stopped at the top level, so a collection with a shipping subdocument showed
shipping: object and nothing inside it — while shipping.city is a perfectly ordinary field
name in MongoDB's own query language.

Subdocuments are now expanded into dotted paths, three levels deep and up to 200 fields per
collection. Arrays are named and left closed on purpose: items.sku reads one value per array
entry, so it does not mean on an array what the same syntax means on a subdocument.

The query agent drafts statements you can actually run

Plan mode never executes anything; it hands you a statement. On these two engines what it
handed you did not run.

• MongoDB: it wrote mongosh — db.orders.aggregate([{ $group: … }]). Correct MongoDB, and
  not what this editor executes, which is the JSON command object. It now drafts that object.
• Redis: it wrote the right commands in the wrong shape — a numbered list of two,
  1) KEYS session:* / 2) GET session:1 — and the server answered
  ERR unknown command '1)'. It now drafts exactly one command.

Both engines now declare, to the model, the statement form their editor accepts. The
absent-nested-field problem above made this worse than a formatting matter: asked about revenue
by region, the agent grouped by $shipping.region, a path the database does not have — and
MongoDB answers a missing group key with a single null group rather than an error, so the plan
looked runnable and was silently wrong. With the fields named, the same question groups by the
field that exists.

Helm chart: 0.1.45

Templates and values are unchanged. The chart's content is the appVersion move to 0.13.1.

Full changelog: 0.13.0...0.13.1