Query as code

As code renders the current query for other tools. It is generated from the command TableCore would send, so it describes exactly what the application runs — including the resolved collection name and any rewrites made from a sample of the collection.

It reads the editor, and plans it afresh each time you ask. To see the command a result on screen actually came from — recorded during that run, not planned again — use Command behind these rows above the grid; it is described in Your first query.

#Three targets

Other target languages — TypeScript, Python, Java, Go — are not available. They are tracked and deferred, and there is no date.

#mongosh

A pipeline is laid out rather than folded into one line: the array opens, each stage starts its own line, and nesting is indented. One renderer produces this and the text that Convert to a MongoDB query puts back in your editor, so the two cannot disagree about what the pipeline is.

db.customers.aggregate([
  {
    "$match" : {
      "active" : true
    }
  },
  {
    "$group" : {
      "_id" : "$country",
      "total" : { "$sum" : 1 }
    }
  }
])

A collection whose name cannot follow a dot is addressed through db.getCollection("order items").

A command carrying an option beside the pipeline — allowDiskUse, collation, hint, a non-default cursor — is rendered as db.runCommand(…) instead. A chain that quietly drops an option describes a different query.

#C# driver

The filter, and for an aggregation every stage, is carried through BsonDocument.Parse rather than rebuilt with the driver's builders. That is deliberate: the stages then travel character for character as the application sends them, and the code works against a BsonDocument collection, with no POCO required.

A $lookup rewritten with builders would be a second implementation of your query, and a reader has no way to tell it from the first.

#C# LINQ

The LINQ tab generates a POCO class and a lambda — and refuses, visibly, when a lambda cannot express the query exactly:

• filters using $regex, $exists, $elemMatch, $nor or $expr,
• a raw command document, which names no shape to map,
• an aggregation pipeline: a lambda for a $lookup or a $group would only be an approximation.

The tab stays visible with the explanation rather than disappearing — a tab that vanishes reads as "not supported at all", which is not what happened.

#What you still have to supply

The generated code is the query, not an application:

• a connection string, a MongoClient and the database — the code names the collection, not how you reach it;
• error handling, cancellation and paging beyond what the query itself carries;
• for the LINQ tab, a real domain class if you have one. The generated POCO is a starting point;
• parameter values. A query written with @name parameters is rendered with the values it ran with, not with placeholders.

POCO field types come from the result on your screen, and only from columns whose values are of one type. A column with inconsistent or unknown types is typed BsonValue rather than guessed from the first row. Types do not affect the query itself, so an empty result can still be rendered.

#What is refused

Only two things, and both by name:

• Not a plannable input — "Only a SELECT statement, a MongoDB shell read or a command document can be rendered as code."
• Not one command — a set operation, or a subquery read while the query is being built. You get the reason and the ordered list of steps, each marked as happening on the server or in TableCore, instead of one of the commands presented as the whole query.

A raw command document is the one input that is not captured from a run: it already is the command, and capturing it would mean executing your query in order to describe it.

A global aggregate — one command that the engine finishes in memory — is not a refusal. The pipeline renders, and the steps travel with it.