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:
- Detect
$binary.subType === "03" or "04" in stringifyCellValue()
- Format the 16 bytes as a standard UUID string with dashes
- 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.
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:$binary.subType === "03"or"04"instringifyCellValue()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
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.