| title | parent |
|---|---|
Attributes Type Migration |
data-storage |
If the type of an existing attribute is changed in the Modeler, mostly the existing column will be dropped and a new column will be created. For some attribute type changes, Mendix tries to convert existing data in the database to the new type.
If data should NOT be converted to the new type, you must remove the attribute in the Modeler and create a new column (with the same name) instead of only changing the data type. Even if you change the type and rename the column, Mendix remembers the old column name and will try to convert the column values if possible.
In the table below, for each data type change, you can see whether Mendix will convert the values.
| to AutoNumber | to Binary | to Boolean | to DateTime | to Decimal | to Enum | to Float/Currency | to HashString | to Integer | to Long | to String (limited) | to String (unlimited) | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| from AutoNumber | X | X | X | ✓ | X | ✓ | X | X | ✓ | – Conversion only possible if length >= 20. | ✓ | |
| from Binary | X | X | X | X | X | X | X | X | X | X | X | |
| from Boolean | X | X | X | X | X | X | X | X | X | – Conversion only possible if length >= 5. Converted to a string by the database, so the value for true and false differs per database. | – Converted to a string by the database, so the value differs per database. | |
| from DateTime | X | X | X | X | X | X | X | X | X | X | X | |
| from Decimal | ✓ | X | X | X | X | X | X | X | X | – Conversion only possible if length >= 20. | ✓ | |
| from Enum | X | X | X | X | X | X | X | X | X | – The name of the enumeration value will be used. The value will be shortened to the right length if it does not fit in the new type. | – The name of the enumeration value will be used. | |
| from Float/Currency | ✓ | X | X | X | – Conversion only possible for actual values that have at most 20 digits before the decimal point. | X | X | X | ✓ | – Conversion only possible if length >= 24. | ✓ | |
| from HashString | X | X | X | X | X | X | X | X | X | – The value will be shortened to the right length if it does not fit in the new type. | ✓ | |
| from Integer | ✓ | X | X | X | ✓ | X | ✓ | X | ✓ | – Conversion only possible if length >= 11 . | ✓ | |
| from Long | ✓ | X | X | X | ✓ | X | ✓ | X | X | – Conversion only possible if length >= 20. | ✓ | |
| from String (limited) | X | X | X | X | X | X | X | X | X | X | ✓ | |
| from String (unlimited) | X | X | X | X | X | X | X | X | X | X | – The value will be shortened to the right length if it does not fit in the new type. |
This is the key to the table above:
| Symbol | Description |
|---|---|
| ✓ | Conversion always possible. |
| – | Conversion is not always possible, or data will be changed during conversion. If conversion is not possible, the behavior is the same as "X". |
| X | Conversion not possible. The original column will be removed and a new column will be created with default values for the existing rows. |
Even if Mendix cannot convert the values of a specific column to another type, you can still manage that manually. First, change the name of the attribute (for example, append the text "Deleted" to its name). Second, create a new attribute with the same name and the new data type. Next, look up occurrences of the old (renamed) attribute in the whole model and change these to the new attribute. Be sure that there is no microflow or form anymore that refers to the old attribute.
Create a microflow in which you retrieve all instances of the entity, loop through the instances and for each instance, read the value of the old attribute, convert the value, store it in the new attribute, and commit the instance. Place a button on an administrator form that calls this microflow.
When you deploy, you have to run this microflow one time, after which you can remove both the microflow and the button pointing to it. Then you can also remove the old attribute.
When you have a one-to-many association and change it into a one-to-one association, be aware that duplicate associations are not cleaned up in the database. For example, a one-to-many association from entity A to entity B allows multiple references: a1 to b1, a1 to b2, etc. One-to-one associations only allow a single reference per object: a1 to b1. Duplicate association entries like a1 to b2 are not cleaned up when you redeploy your app.