I can understand the reasoning, but I just had a case where being able to set an embeds_many to nil would have saved me a lot of trouble.

I have an existing schema/table with a field :foo, {:array, :string}. This field contains encoded values (I know, not the best design, but thats just how the database was designed quiet some time ago). I need to migrate to a new embeds_many :foo_new, MyCustomStruct. The table is rather large, so I can’t migrate all of the data at once and instead have to keep both columns running simultaneously for a while, i.e. the migration happens in the background.

Now in an API endpoint, I have to decide which of the two fields is the one, that I have to read the data from and send it to the client. Initially I wanted to allow nil for the :foo_new embed, so I could use it as a marker that tells me whether the record has already been migrated from :foo to :foo_new. This would have worked well, because [] is a valid value and I can’t use it to decide whether the data has been migrated. To be more specific, the code could have ignored the old :foo field and just write the :foo_new field, so as soon as there is a value in there, I’d have known, that the migration logic did run and :foo_new is the new source of truth.

It even works in production, because the database allows NULL values and Ecto returns them as nil for the embeds_many. However, things start to get problematic as soon as I write tests, because then I have to write a lot of workarounds to get the nil values into the test database, effectively rendering ExMachina etc. useless, because the thousands of existing tests now insert foo: [...], foo_new: [] and I can’t opt out of that behavior.