Hi, I am looking into best practices on how to handle data model changes. We now have a situation where we need to do a slight change in a mixin used in multiple content-types. This change means that the controller handling this specific data might encounter both the old data model and the new. This won’t work unless we migrate the existing data to the new model or we create code that handle both the old and the new model. The latter is something I really want to avoid.
What I want is a safe way to “migrate” existing content into the new model, and in a broader sense; I would like to have a strategy to handle these kinds of changes in the future.
For now we create simple services. It’s working well, but something like the EntityFramework Migrations, that do the job automatically would be awesome!
An example: https://pastebin.com/90j9CGks
Ok. Very interesting!
I suppose you will have to take down the site while you do this kind of data migration?
How do you run these services when deploying? Do you just hit the different endpoints after deployment?
If the content count is large, I suggest you to set the time off for users. We run the services in any browser if there are only a few contents, just entering its url or creating paginated macros in some HTTP Request App (Like Postman) so you can receive a param “start” and use it on the query content. I’ve paginated around 500 contents for each request. More than that my nginx got timeout
You will be happy to learn that for 7.0 we will provide an out-of-the box concept for this scenario. The short version is that apps may store a “data-model” property in the system repository, for instance data-model: 1, and when you ship and deploy a new version of your app it may require data-model: 3. XP would then look for upgrade script 2 + 3, and run them (possibly before) starting the rest of the application.
So, 3.5 years later and we still do our upgrades to data models by dumping data, downloading it, open it in VScode, search-and-replace, then upload it again. We change a few times a year the name of a part, or the name of content types, or more common: name of an input field - especially in the startup phase. It would help a lot to have a system built into Enonic XP to handle this.
So, how are you progressing with plans on this upgrade model system?
And, since this is not implemented today and we still upgrade/change a lot, what is best suggestion with the tech available in 7.6. With libContent and modify we need to do the publishing step in code, which could mess things up if the contents wasn’t published before. Also change part name cannot be solved in libContent right? We need to go deeper, libNode, but is it possible to target master-nodes directly without spawning new versions placed in draft?
Few scenarios we need to solve:
part name (folder) is changed (old name: images, new name: image-list)
input field changed name
input field is removed
Advanced: move specific fields from content type to a field within a part instead.
