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.