Skip to content

FEAT: Display Legacy UUID (Binary subtype 3) as formatted UUID string for MongoDB #1394

@niklasbeinghaus

Description

@niklasbeinghaus

Is your feature request related to a problem? Please describe.

When viewing MongoDB documents with Legacy UUID fields (Binary subtype 3), DbGate displays them as raw hex bytes. While v6.7.0 greatly improved binary field handling (#1240), there's no distinction between a generic binary blob and a Legacy UUID — both render the same way. This makes it difficult to read, compare, and work with UUID values that were written by Java, C#, or Python MongoDB drivers using the legacy format.

This affects any database created roughly between 2015–2020 with drivers that defaulted to Binary subtype 3 (Java, C#, Python). The BSON specification explicitly states that tools "should properly handle subtype 3". MongoDB's own Compass still has open feedback requests about this, and there are 16,000+ Stack Overflow views on related questions — it's a real gap across the GUI ecosystem.

Describe the solution you'd like

When a Binary field has subType: "03" (or "04"), display it as a formatted UUID string (e.g., 550e8400-e29b-41d4-a716-446655440000) instead of raw hex in the data grid.

The data already flows correctly — EJSON.serialize() preserves { $binary: { base64: "...", subType: "03" } } through the pipeline. The change would be in the display layer:

  1. Detect $binary.subType === "03" or "04" in stringifyCellValue()
  2. Format the 16 bytes as a standard UUID string with dashes
  3. Preserve the subType on round-trip (edit → save)

Bonus (optional): Legacy UUID byte ordering varies by driver origin. An advanced version could offer a preference for the encoding (C#/Java/Python), but even without that, displaying the raw bytes as a UUID string is a major improvement over hex.

Describe alternatives you've considered

  • Manually converting hex to UUID format outside DbGate — works but breaks the workflow
  • Using Studio 3T for UUID-heavy work — proprietary, not ideal for daily use
  • Migrating all data to subtype 4 — not always feasible with legacy systems

References

I'm happy to contribute a PR for this if there's interest — the scope is narrow and the backend already handles the data correctly.

Metadata

Metadata

Assignees

Labels

solvedPushed into GIT, but not yet released (after release issue will be closed)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions