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

ObjectId's on Embedded 1:1 Documents

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

      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
      end
      
      class Name
        include Mongoid::Document
      
        field :first, type: String
        field :middle, type: String
        field :last, type: String
      
        embedded_in :contactItems
      end
      

      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.

            Assignee:
            Unassigned Unassigned
            Reporter:
            droppedoncaprica droppedoncaprica
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: