Uploaded image for project: 'Mongoid'
  1. Mongoid
  2. MONGOID-4105

ObjectId's on Embedded 1:1 Documents



    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 6.0.0
    • Component/s: None
    • Labels:


      Is there a certain reason why ObjectId's are added to embedded 1:1 documents? Let's take a look at data in this format:

        name: {
          first: "Albert",
          middle: "C",
          last: "Engelbrecht"
        email: "email@gmail.com",
        phone: "(999)999-9999"

      If I want to enforce types for the name fields, I'd have to create a Document structure like this:

      class Contact
        include Mongoid::Document
        field :email, type: String
        field :phone, type: String
        embeds_one :name
      class Name
        include Mongoid::Document
        field :first, type: String
        field :middle, type: String
        field :last, type: String
        embedded_in :contactItems

      When I create a new Contact, the name hash includes an ObjectId.

        name: {
          _id: ObjectId('558b2df94465764c9e000001'),
          first: "Albert",
          last: "Engelbrecht",
          middle: "C"

      Basically right now it seems like you have to decide on a tradeoff. You either have to forgo type checking for these embedded hashes, or you have to accept the fact that there are ObjectId's injected on all of these fields.

      This was why I was curious, why are there _id}}s added to embedded hashes by default? Adding {{_id fields to array of hashes totally makes sense, as then you have a unique identifier to update on outside of the array's index, but to me adding {{_id}}s to embedded hashes seems unneeded.

      I know there was an option to globally turn of {{_id}}s on embedded documents, however that was removed. I'm not trying to criticize, I was just interested why this was done this way.




            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: