Java Driver
  1. Java Driver
  2. JAVA-403

UUIDs are stored as little endian (should be big endian)

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major - P3 Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: Codecs, Configuration
    • Labels:
    • Environment:
      MacOS X 10.6 (which implies a little endian x86/64 CPU)
    • # Replies:
      19
    • Last comment by Customer:
      false

      Description

      In python:
      >>> import pymongo
      >>> import uuid
      >>> from pymongo import Connection
      >>> c = Connection('localhost', 27017)
      >>> db = c.test
      >>> db.foo.insert(

      {"python": uuid.UUID("aaf4c61d-dcc5-e8a2-dabe-de0f3b482cd9")}

      )
      ObjectId('4e318fb98f1e81eac4000001')

      In java:
      UUID id = UUID.fromString("aaf4c61d-dcc5-e8a2-dabe-de0f3b482cd9");
      Mongo mongo = new Mongo();
      DB db = mongo.getDB("test");
      DBObject dbo = new BasicDBObject();
      dbo.put("java", id);
      db.getCollection("foo").insert(dbo);

      Result:
      > db.foo.find()

      { "_id" : ObjectId("4e318fb98f1e81eac4000001"), "python" : UUID('aaf4c61ddcc5e8a2dabede0f3b482cd9') } { "_id" : ObjectId("4e318fc12746ac3aa375aee9"), "java" : UUID('a2e8c5dc1dc6f4aad92c483b0fdebeda') }

      (yes, with the patch from SERVER-1201 applied)

      Java seems to serialize/deserialize the UUIDs as little endian according to BSONEncoder.java, line 354

      Changing this would however break a lot of applications out there. However, the python/java incompatibility is really bad, so it should be fixed in my humble opinion...

        Issue Links

          Activity

          Hide
          Philipp Schneider (coresystems)
          added a comment -

          Hello,
          we have patched the driver and using the patched version since a few month. We have just upgraded to the newest driver version.
          You can download the patched version here:
          https://github.com/mila-labs/mongo-java-driver/

          Use at own risk and only if you have NO DATA yet in the database

          Show
          Philipp Schneider (coresystems)
          added a comment - Hello, we have patched the driver and using the patched version since a few month. We have just upgraded to the newest driver version. You can download the patched version here: https://github.com/mila-labs/mongo-java-driver/ Use at own risk and only if you have NO DATA yet in the database
          Hide
          Nils
          added a comment - - edited

          The fix appears to still use subtype 3, which will break backwards compatibility. Any reason not to switch to subtype 4, which arguably is is the correct subtype, while retaining backwards compatibility?

          Show
          Nils
          added a comment - - edited The fix appears to still use subtype 3, which will break backwards compatibility. Any reason not to switch to subtype 4, which arguably is is the correct subtype, while retaining backwards compatibility?
          Hide
          Philipp Schneider (coresystems)
          added a comment -

          @Nils
          For our case we needed Subtype 3 because Python was/is using the same database. We did not needed backward compatibility because the database was empty.
          Python and Java needed to read and write the same database.
          Our patch is not a general fix for this issue. It is a quick and working solution which only works if you start with an empty database and do not care about backward compatibility.

          From a mongodb user point, it would be nice if the final fix/solution would have an option where the user of the driver can define if he wants to use subtype4 or subtype3 (3 will have no backward compatibility). On option in some kind of settings would be nice.

          Show
          Philipp Schneider (coresystems)
          added a comment - @Nils For our case we needed Subtype 3 because Python was/is using the same database. We did not needed backward compatibility because the database was empty. Python and Java needed to read and write the same database. Our patch is not a general fix for this issue. It is a quick and working solution which only works if you start with an empty database and do not care about backward compatibility. From a mongodb user point, it would be nice if the final fix/solution would have an option where the user of the driver can define if he wants to use subtype4 or subtype3 (3 will have no backward compatibility). On option in some kind of settings would be nice.
          Hide
          Bernie Hackett
          added a comment -

          Philipp, you can already do this in PyMongo:

          http://api.mongodb.org/python/current/api/pymongo/collection.html#pymongo.collection.Collection.uuid_subtype

          Valid settings are OLD_UUID_SUBTYPE (3 - the current default), UUID_SUBTYPE (4 - will be the default in some future release), JAVA_LEGACY, and CSHARP_LEGACY.

          This is a per-collection setting so that you can use subtype 4 in new collections but use legacy byte orders in existing collections.

          Show
          Bernie Hackett
          added a comment - Philipp, you can already do this in PyMongo: http://api.mongodb.org/python/current/api/pymongo/collection.html#pymongo.collection.Collection.uuid_subtype Valid settings are OLD_UUID_SUBTYPE (3 - the current default), UUID_SUBTYPE (4 - will be the default in some future release), JAVA_LEGACY, and CSHARP_LEGACY. This is a per-collection setting so that you can use subtype 4 in new collections but use legacy byte orders in existing collections.
          Hide
          Jeff Yemin
          added a comment -

          Moving to 3.0 release, unfortunately. The only way to do this in 2.x is with the DBEncoder/DBDecoder framework, and we're likely going to be getting rid of that framework in 3.0.

          Show
          Jeff Yemin
          added a comment - Moving to 3.0 release, unfortunately. The only way to do this in 2.x is with the DBEncoder/DBDecoder framework, and we're likely going to be getting rid of that framework in 3.0.

            People

            • Votes:
              7 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since reply:
                1 year, 13 weeks, 3 days ago
                Date of 1st Reply: