Why does `embeds_many` enforce a default of `[]`?

Don’t see how this makes the default for embeds many confusing. What else could this value be? And a list of nothing is an empty list, no?

I get what you mean that it could say there is no value here, but that is if you think of the embed many field as the value. I think of the values as the things being embedded.

Using a list over nil probably saves us from nil checks all over the place. Would you prefer to check if it’s nil before you try to operate on it every time?

In every database I can find the default for a column that is a list is always null.

It’s also the default for every field and at least one of the two embeds_.

This stands out exclusively against common design and expectation.

Beyond the fact that it actually does impact the database (again double the space cost), there is a massive difference between “this column has no value” and “this column is an empty list”.

You could submit a proposal to the mailing list to make the default configurable and see what they say: https://groups.google.com/g/elixir-ecto.

Changing the default for everyone probably isn’t a good idea because it will break existing code.

I’m not sure why it is empty list but it might have something to do with the fact that embeds and associations are treated very similarly. And when you attempt to preload an association it will give an empty list when none are found. This makes sense because the result of the preload is defined as a list of associations and not a nullable column.

I’ll post there next. I wanted to do it here in case there was something I was missing.

I would argue this is the only correct default. Embeds many represents associated records of which there can be 0 or more.
The number of records in NULL would be undefined, which would be incorrect.

Embeds are modeled to align closely with assocs and for assocs empty set doesn‘t mean there‘s a column somewhere set to NULL, but it means there‘s no rows at all. It makes sense to default that field to empty list, because as mentioned before it‘s much cleaner not to check for nil and empty list everywhere.

I can see it both ways: thinking about it as a nullable column with a complex datatype or as denormalized associations.

This is it.

Ok, but embeds_many implies a collection of stuffs. I would say that if you have a complex type that might be null or a list, then you have one embed that might be null or a list, not a collection of things that might be in the list.

I’m not a not null radical ala CJ Date, and if you do want to have a complex type with a maybe list, model it as such (and it’s still probably not great). But if you call something embeds_many or has_many it implies a countable thing and NULL is not.

Then again op stated:

Which is plainly wrong.

Ok, but embeds_many implies a collection of stuffs. I would say that if you have a complex type that might be null or a list, then you have one embed that might be null or a list, not a collection of things that might be in the list.

That’s a good point. I guess there’s a bit of tension if someone wants to take advantage of embedded schemas for a list type but also wants to treat it as a nullable column.

There is sometimes value in allowing both NULL and empty list. The former might signal the data is missing while the latter might signal the data is complete and there is nothing to report.