TableCore

Browsing and editing documents

The results grid is type-aware and, when the result allows it, editable in place. This page is about what "allows it" means and what happens when you save.

The grid keeps BSON types

A value is shown with its BSON type rather than flattened to text. That is not decoration: a string "42" and an Int32 42 are different documents, and a client that hides the difference will eventually cost you an afternoon.

Editing preserves the type. A JSON string stays a string; ObjectId, dates and the other special types are produced only from an explicit cell type, never guessed from what the text looks like.

The results grid, with each value labelled by its BSON type — int32, string, boolean, document and array.

Editing a whole Document or Array cell as text uses Canonical MongoDB Extended JSON, and also accepts ordinary valid JSON. Editing a single nested cell goes through the typed path, so a nested ObjectId, DateTime, Int64, Decimal128 or Binary/UUID — including its subtype — is not flattened to a string on the way.

When a result is editable

Editing needs to know, without guessing, which document in which collection each row came from. That provenance is produced by the engine from the parsed query and travels with the result; it is never re-derived from the displayed column name or from what is currently selected in the explorer.

ResultEditable
Single collection, includes the original _idYes
Shell db.collection.find(…) including _idYes
Projection that removed _idNo — nothing to write back through
JOIN, UNION, aggregate, GROUP BYNo
Aliases, computed fields, partial projections of nested documentsNo
Raw MongoDB command documentNo — it carries no provenance
A field name containing a dot, or starting with $No — update operators would read the name as a path
Any result on a read-only connectionNo, and it says so for that reason

No provenance is a fail-closed state. The grid names which of these applies rather than saying only "read-only" — being sent to rewrite a query that was never the problem is the wrong kind of help.

Collection and field names are compared case-sensitively on the write path. MongoDB can hold name and Name in the same document, and merging them would lose one.

What is sent when you save

Only what changed: new and modified documents, deleted identifiers, and removed columns. The grid tracks changed fields per row and does not resend values you did not touch.

_id cannot be removed or changed while editing an existing document. Removing a column applies only to the _ids visible in the result you edited.

The preflight

Before the first write, TableCore normalises every value and then checks: duplicate or conflicting _ids, that the documents you edited still exist, and that explicit _ids on new documents are still free.

Existing documents are written with upsert off, so a document deleted by someone else in the meantime is not resurrected from a partial projection, and a new document with a taken _id does not overwrite what is there.

Transactions, where there are transactions

On a replica set, a sharded cluster or a load-balanced deployment, the preflight and a multi-document save run inside a driver transaction.

A standalone MongoDB has no multi-document transactions. The preflight and doing the deletes last limit the exposure, and the interface reports the counters of a partially committed save explicitly, keeping your draft so you can refresh and finish by hand.

Unknown is a state, and it is reported as one

If the driver returns an unknown commit result, or the connection drops during a standalone save, TableCore does not assume success and does not assume failure. It says the outcome is unknown and asks you to read the data again. Guessing either way is how you end up applying an edit twice.

Drafts

Grid edits live in the tab as a draft. Closing a tab, closing several tabs, or re-running the query all ask before discarding one.

A draft does not survive a restart, and that is deliberate rather than an omission. It describes untouched rows by their position in a result that no longer exists after a restart, so a restored draft would put your edit markers on somebody else's records. The query text comes back; the draft does not, and the confirmation on close is there because of it.

Renaming a database or collection

MongoDB has no atomic database rename. TableCore copies documents in batches along with the indexes, verifies the document count and the set of collections, and only then drops the source. Views and collections with special options are refused rather than copied with their semantics lost.

Pause writes to a database while it is being renamed. The dialog says so too.

Next