Mongo `_id` Structure

[thehabes]

101 and #102 and #107 Depends on this.

In our examples we show that the private mongo objects look like

{
  "_id": {
    "$oid": "65f48c9a4da4e4b8c656d0d2"
  }
  ...
}

Mongo does not save _id properties this way anymore. I think mongodb has moved on from this.

{
   "_id":{
      "date":{
         "date":1,
         "day":1,
         "hours":9,
         "minutes":0,
         "month":7,
         "seconds":5,
         "time":{
            "$numberLong":"1470060005000"
         },
         "timezoneOffset":300,
         "year":116
      },
      "inc":1200311602,
      "machine":-458219467,
      "new":false,
      "time":{
         "$numberLong":"1470060005000"
      },
      "timeSecond":1470060005,
      "timestamp":1470060005
   },
   "__oops_@id":"http://165.134.105.29/annotationstore/annotation/{ \"date\" : { \"date\" : 1 , \"day\" : 1 , \"hours\" : 9 , \"minutes\" : 0 , \"month\" : 7 , \"seconds\" : 5 , \"time\" : 1470060005000 , \"timezoneOffset\" : 300 , \"year\" : 116} , \"inc\" : 1200311602 , \"machine\" : -458219467 , \"new\" : false , \"time\" : 1470060005000 , \"timeSecond\" : 1470060005 , \"timestamp\" : 1470060005}",
   "@type":"oa:Annotation",
   "motivation":"oa:describing",
   "forProject":"broken_books_debra",
}

Instead, all of our objects are one of the variations you see below.

 {
    _id: ObjectId("65fc7d626b71f91564b53d98"),
    '@type': 'Project',
    name: 'Test Project'
  }

  { _id: '11111', '@type': 'Project', name: 'Test Project' }

  { _id: '22222', '@type': 'Project', name: 'Test Project DDDD' }

  {
    _id: '65fc8de6370a85dd68394992',
    '@type': 'Project',
    name: 'B Test'
  }

None of these "id" structures match on what we show in our examples, which make functions like getById() somewhat undefined right now since there is a question around what the "id" actually looks like so we can access it.

 "_id": {
    "$oid": "65f48c9a4da4e4b8c656d0d2"
  }

I think all we get nowadays is mostly just that string_that_is_id that is made of parts that you can lightly decode for information, like if you choose to make the _id off of Date.now(). We can make _id an object if we want, but it isn't just that way anymore, beyond the fact that ObjectId("string_that_is_id") is probably an Object.

What do we want to solidify around as the "id" for the objects in the private tpen MongoDB Collections?

https://www.mongodb.com/docs/manual/reference/method/ObjectId/

[cubap]

My vote is to expect (and possibly enforce) that the _id is "ObjectId(hexstring)".

I think this is something the mongoDriver needs to know and not the person trying to force something in. The "getById(hexString)" should ultimately normalize and interpret the input.

• If it is an appropriate hexString, then it becomes "ObjectId(hexstring)"
• If a string, it is converted to hex and padded then ObjectId(HEX)
• If it is an integer, it can be used directly in ObjectId(INT)

This can be planned just for a "getById()" since using find() with an _id is always going to be a findOne()

[cubap]

One also may be able to understand a requirement to only allow an "id" that is generated through a "reserveID()" sort of method. In this way, if you send in an _id that isn't a hexString, it can just be rejected. In our case, this could always send back a ObjectId.toString() hex and validate that it is easily on a create. If it were a different database, it could just validate differently.

[thehabes]

[cubap]

database.controller.asValidId(id) is available now, so any number or string can be turned into a valid Id