Changing attributes and associations in your production-running app

It’s happens in every app..

For a new feature you have to move or delete attributes or association in a new version of your app. When you are working on the first version of your app, there is no problem. Delete or copy/paste the attributes and associations in the domain model. The Mendix Modeler will do some error checking and fix all the usages.
In this post I’ll share my experience how to handle changes and deletion of attributes/associations. I’ll also provide you some best practices how to handle these changes with preserving the important data of your customer.

Model

In this example I’ll use the following domain model to illustrate a change

We want to move the e-mail address to the Person entity. The following steps have a precise order in steps:

1. Make sure you have no changes left in your app (especially in your domain-model)
2. First make your new attribute in the Person entity.
3. Commit this change to the team server (you can use a branch if necessary)
4. To check your app where the e-mail attribute is used you can do this in two ways:
   1. use the function Find usages and find every use of the attribute or association
   2. or just delete the existing attribute (but do not commit) and fix all the errors and revert the domain model.

At this point all of your microflows, pages etc. are changed to use the new e-mail attribute of the Person entity.
For conversion purposes it’s handy to rename your old attribute or association with a post- or prefix OLD/BLA/DELETETHIS. This approach will reminds you to clean up your model later after the conversion.

Data

Now you have an unused attribute in the Account entity but in the production version of your app the database contains data you want to preserve. The best way to move the data is to create a Microflow which will copy the data to the new entity with a simple Retrieve from database with a constraint on an empty email attribute in the Person entity and a loop:

I always add some logging to check how many accounts were involved. If you have a lot of records (for example 1.000.000+) keep the performance in mind and create a List before the loop, and add the record in the loop to the list. After the loop commit this list.
After creating a database-backup and running this conversion you can delete the old attribute in you domain model. The used conversion microflow you can trash it also (if it’s a complex and maybe re-usable exclude it from the project or export the microflow). After the next deployment of your app the attribute and data will be deleted.

Best practices

• Automate execution of conversion flows

Of course you can have full control over the moment of execution of your microflow but you can also forget to execute it. In our Appronto Commons module we have some conversion helpers; check it out.

• Datatype changes

Without warnings for damaging existing data watch out for changing datatype. Mendix will substring to the new size in case of changes in string size. But be aware of changing other datatypes too and always check your data in a development environment.

• Runtime OQL queries

If you use for example our Reporting for Mendix module and you have designed queries with the changes entities, check and correct them after you have synced your new model with the Mendix Model Reflection module

• Deleting and creating an association with the same name isn’t the same association and deletes the relation(and your data) in the database when you commit this change and deploying your app.

• Instantly create a story in the next sprint to clean up unused and converted attributes and associations.