Support for Mongo BSON UUIDs 🍃

[mfen]

Our team is working with Mongo's BSON Binary UUIDs (sub-type 4), but we don't see a supported way to use them with Meteor. Meteor's mongo and ejson packages seem to work with Uint8Array and persist them to the default Binary type (sub-type 0).

Unless we are overlooking an existing solution, we are open to contributing UUID support, but would first need to confirm the scope of what an acceptable implementation might look like.

Proposal

1. Add hooks to mongo/mongo_driver.js which allow overriding the handling of certain data types in replaceMongoAtomWithMeteor and replaceMeteorAtomWithMongo.

2. Contribute a package that allows optional UUID support by using these hooks to handle UUIDs similar to ObjectID. This package would:

   • Add a Mongo.UUID class and EJSON custom type similar to Mongo.ObjectID
     • e.g. { $type: 'uuid', $value: <hex_string> }
   • Use the above hooks to override:
     • parsing of Binary sub-type 4 to Mongo.UUID instead of Uint8Array
     • persistence of Mongo.UUID to Binary sub-type 4 instead of sub-type 0

Any feedback on likely difficulties to overcome or preferred implementation would be greatly appreciated.

Related: We are not looking to add support for UUIDs for ID generation, as has been requested in these other feature requests, but this might be a partial step towards support:

• Support non-ObjectId ids #5471
• Support for UUID option in idGeneration meteor-feature-requests#371

[jankapunkt]

I think if we talk about "support" it should be both, reading and writing. We have a similar urge but with native ObjectId, where we connect to an existing MongoDB from a plain node app and we would like not only to read their docs (which is working fine with a custom EJSON class, similar to your proposal) but the generation part is basically not working.

Related: meteor/meteor-feature-requests#428 (the intial post does not look like it's about native Mongo ObjectId but it's basically what's intended there).

I think both of these use-cases are very close to each other

[mfen]

Anyone from mdg able to comment on whether a PR for part (1) of the above approach would be accepted? Our company's time window is narrowing for making a decision on contributing this support or going with some other workaround for the time being.

Thanks.

[StorytellerCZ]

How would you see the API? Can you provide an example?

[mfen]

We could expose the replaceXAtomWithY functions via MongoConnection.prototype for extension, similar to how some packages wrap/extend Collection, e.g.:

MongoConnection.prototype.mongoAtomToMeteor = function(value) { ... }
MongoConnection.prototype.meteorAtomToMongo = function(value) { ... }

Then any optional atmo package could extend it by wrapping these methods via MongoInternals.Connection.prototype, handling specific types and passing other types through to the original.

e.g. I have a working proof of concept for UUIDs with:

import muuid from 'uuid-mongodb';

// Originals to wrap
const { mongoAtomToMeteor, meteorAtomToMongo } = MongoInternals.Connection.prototype;

MongoInternals.Connection.prototype.mongoAtomToMeteor = function (value) {
  if (value instanceof Binary && value.sub_type === Binary.SUBTYPE_UUID) {
    return new MongoUUID(value.buffer);
  }

  return mongoAtomToMeteor(value);
}

MongoInternals.Connection.prototype.meteorAtomToMongo = function (value) {
  if (value instanceof MongoUUID) {
    return muuid.from(value.toHexString());
  }

  return meteorAtomToMongo(value);
}

I'm open to feedback and any other preferred implementation that would be more readily accepted.

[filipenevola]

Yes @mfen, a PR adding the necessary hooks would be reviewed and released asap 😉