I don't think supporting $options['default'] in the FieldMapping is an expected API today (if you go that way, almost all fields of the FieldMapping end up being used to configure the DBAL column options, so you could argue that they could all be deprecated in favor of $options, but this leaks the DBAL API in the public API of the ORM.

I don't think this deprecation makes sense.

I would rather deprecate passing options for option names that are handled by SchemaTool based on the field mapping.

I don't think supporting $options['default'] in the FieldMapping is an expected API today

Maybe not today, but in the past, that seemed to be the only way to do it: https://stackoverflow.com/a/53224518/353612

Also, notice how the Column mapping attribute does not have a default property:

this leaks the DBAL API in the public API of the ORM.

Are you suggesting that people should not refer to the new DBAL value objects in their mappings?

I would rather deprecate passing options for option names that are handled by SchemaTool based on the field mapping.

I don't really understand what that means… can you please elaborate? Are you maybe talking about these:

In any case, I could not find documentation on this feature. I think that usually default values are derived from the default value of the property, which might explain the lack of docs. However for DateTime field, I don't think it would be possible to have some kind of magic value that we would translate later on into DBAL value objects, since you cannot use new to initialize the default value of a property

oh, I was not aware that FieldMapping had this default property but not Column. Then, I'm fine with that deprecation (the main public API is clearly Column there)