Question

Data migration and inheritance

4

We've got a situation where an application in use is being added to in a way which requires some attributes of an existing entity type to be moved to an abstract supertype, and a new subtype created which inherits these attributes and adds others. To simplify, we are adding credit note handling to a system which already handles invoices, and these two things have much in common. Suppose that in the existing system we have type Invoice with invoiceNumber: int, issueDate: DateTime and amount: Currency, toghether with a bunch of attributes to do with the invoice content and payee. Now suppose we want to add CreditNote with a bunch of different attributes, but to let both CreditNote and Invoice inherit from Bill, and that the above attributes will be moved from Invoice to Bill. My understanding is that when this arrangement is put live Mendix will create the new schema but will not move the existing data from Invoice to Bill. Instead it will move it to tables designated "delete" something-or-other and create the new fields of Bill with empty values. Is that correct please? And if so, it is possible and advisable to use SQL scripts to move the data across from the "deleted" fields of Invoice to the new ones in Bill, or does Mendix or its API provide migration facilities for this purpose?

asked 2010-11-02

Martin Bucknall

2 answers

Sjoerd Breur · Answer 1 · 2010-11-02

I believe you are correct in that if you were to remove the mentioned attributes off Invoice, add the same ones to Bill, and make Invoice inherit from Bill, you will not automatically see these attributes moved to the equivalent Bill attributes. (I don't think there's enough data here for the system to determine without doubt that these attributes are one and the same, though people from RnD probably know more about that)

There's no specific options inside the Business Modeler for migration, however this sounds like an issue which should be solvable using a microflow. If you were to first add the inheritance from Bill (and those three attributes which are moved from Invoice) to the project, it should be fairly easy to create a microflow that loops over all the Invoices and write the data to the corresponding attributes which are now on Bill. After that you could just remove those attributes from Invoice, as the data has been moved to the portion of the entity stores in the Bill table.

(Essentially I think a microflow retrieving all Invoice objects, and then looping over the Invoice objects with a Change Object action which copies the data from the three attributes on Invoice to those on Bill should do the trick)

Sebastiaan van den Broek · Answer 2 · 2010-11-02

We do not provide an API for migration purposes, so yes it's adviseable to migrate manually using SQL scripts. We don't create new schema's but we do create new tables. The records in Invoice will be moved to the new 'Bill' parent entity, but the attributes that are moved to 'Bill' will have to moved manually and these will be indicated with deleted_attributename in the Invoice table. I probably don't have to tell you this but it's a good idea to backup your data thoroughly beforehand.