I know that most changes to the an AM model are implemented as non-destructive additions to the data model. However, what happens when we need to change the data type of an existing attribute? For example, the need to expand the Name field from varchar(50) to varchar(100).
How does AM handle this? Is the solution similar to forum post "changing cardinality in an operational model"? And are all the relationships properly recreated?
AM makes the statement that all previous versions of the model exist as a subset of the current model. Does a change like this invalidate the previous versions of the model?
If you are pure of heart, you create a new attribute with the correct datatype and leave the old one in place. In practice though, a more pragmatic approach would be to rename the Name to Name_old and create a new attribute with the correct datatype and migrate the data, then remove the old one. This is of course only possible when the new data type is "larger" then the old one, but I suspect all changes of this nature result in such types.
Regarding destructive changes in the anchor model. How should one change static attributes to historized attributes after data has been loaded in the static attribute? When you toggle the static attribute to be historized in the model the generate SQL script will not alter the static attribute table and add a ChangedAt column.
Would the same approach be fit? 1) Rename old static attribute table 2) add historized attribute table 3) migrate static attribute data to historized attribute table 4) delete old static attribute table?
The purist way seems to hold more to AM, but I can see where it could get out of control. With the practical approach, besides renaming the original attribute, are there any other manual steps that need to be performed to properly (re)generate the AM components (ie tables, views, FKs)?