The Impact of Modeling Changes on Existing Data

While developing your solution using RapidCMDB, rarely you will be able to get modeling right at the first try. Typically, modeling is an iterative task, where you model your domain classes, run them with some data and make necessary adjustments. Since changes to the modeled objects are made in development, it is OK to lose data. You can remove all data, deploy your modeling changes and rerun your connectors or other scripts to populate data in RapidCMDB.

However, sometimes, changes are necessary in a production environment. These changes are more complex if it is not possible to remove existing data and start over as in a development environment. It is necessary to understand the impact of modeling changes on existing data.

Modeling changes  can be divided into 2 broad groups:

• Simple changes that require no user intervention. Changes like adding a property to a modeled class, will not invalidate any existing data.
• Changes that can not be handled automatically. These changes some user intervention, either before the modeling upgrade, or after.

Modeling Changes that can Safely be Performed in a Production Environment

• Model Add

• • Add a new modeled class that is not a parent of any existing modeled classes

• Model Delete

• • Delete a modeled class that is not a parent of any existing modeled classes

• Property Add

• • Add a non-key property to an existing modeled class
  • Add a key property to an existing modeled class

• Property Delete

• • Delete a non-key property

• Property Update

• • Make a federated property non-federated
  • Make a non-federated property federated
  • Make a non-key property, key

• Relation Add

• • Add One-to-One Relation between 2 modeled classes
  • Add One-to-Many Relation between 2 modeled classes
  • Add Many-to-Many Relation between 2 modeled classes

• Relation Delete

• • Delete One-to-One Relation between 2 modeled classes
  • Delete One-to-Many Relation between 2 modeled classes
  • Delete Many-to-Many Relation between 2 modeled classes

• Relation Update

• • Change cardinality from One-to-One to One-to-Many
  • Change cardinality from One-to-One to Many-to-Many
  • Change cardinality from One-to-Many to Many-to-Many

Modeling Changes that Require Data Migration

• Model Add

• Model Delete

• Model Rename

• • See Model Delete above

• Property Delete

• Property Update

• Relation Update

Data Migration

• Prepare export script: Modify the sample export script or write a custom script to export data to a file or a database.
• Prepare import script: Modify the sample import script or write a custom script to import data from the file or database. Import script usually performs data correction as well, as objects are imported back into RapidCMDB. However, you can use a separate script for this to be executed on the exported data, before the import.
• Remove the exported objects from RapidCMDB.
• Make necessary modeling changes*, Generate* the modeled classes and restart the application to deploy the new model.
• Execute the import script to import modified data back into RapidCMDB as new objects.

Please see Export-Import Utility document for more information.