Priority: Major - P3
Affects Version/s: None
It is possible, in a Mongoid application, to declare a type on a field which already contains data in the database of other, incompatible types. When retrieving such data, Mongoid is presently inconsistent with what happens:
- Some types raise an exception.
- Some types replace the database value with nil.
- Some types replace the database value with a "default" value for the type.
- Some types end up placing a value of the wrong type in the field (thus essentially overriding the user's field type specification).
Research by dmitry.rybakov:
This manifests as:
Note that the first of the four options causes difficulties when working with data that is stored in the database, the second two options can be considered to lose data, the last option can cause weird application errors down the line.
Behave consistently with all types that it supports
Document its behavior
Possible solutions could involve a global or a per-field option as to how to handle values in the database that cannot be cast to the defined field type.
The action items are as follows:
create the ``validate_db_attribute_types`` flag
document feature flag
standardize demongoization functionality (always raise, rescue on flag)
create InvalidDBValue error
write release note for this change
add documentation to Uncastable values section
add note to custom types protocol
- Revised design *
- Deongoization of uncastable values will always return nil
- Original value will be accessible in attributes_before_type_cast (will be done in