Your application has been already distributed to your client and you no longer have access to the production database. Your client admin is responsible for that. But since development never stops as you know, you client asked for some model modification and some new application models (lets say 10) have been developed by your team and you want to sent them to the admin to update the application.
eXpand IO module is the right one for the job
Step1—Create a serialization graph to configure which objects/values you are going to export
In order to create a serialization graph for an object type you have 1st to create a Serialization Configuration Group, that is just a container to help you organize your graphs
Given that you want to export Models you have to create a graph for the ModelDifferenceObject persistent class
When you set the Type To Serialize editor value (1) IO module will automatically fill the values of the nested listview (2) by populating the properties of the Application Difference object, and also will create graphs for objects that are connected with Application Difference object (3)
Step2--Clean automatically created graph
You may wondering how the graphs in the number (3) of the above image are created. If you see the domain model of the ModelDifferenceObject you will see the relation between all these objects.
So what IO module does goes through all those relations and create graphs for each one of them, since due to object polymorphism it is impossible to know the type of the object from the start. But you do!! You know that you are interested to export only ModelDifferenceObjects and not RoleModelDifferenceObject or UserModelDifferenceObject so you could delete all other graphs as showh bellow
Step3—Choose Serialization Strategy
This screenshot are taken from eXpand feature center and as you see there are some properties that we may not want to export such as City,UserFilter,Skin. We can exclude them from the export process by choosing a DoNotSerialize strategy
Now for the most interesting and hard step. As you see from the domain model above ModelDifferenceObject has M-1 relation with the PersistentApplication object, also by the name of PersistentApplication one can understand that the already distributed application already have that object and we not want to export its properties but only its key, so choosing a SerializeAsValue strategy will solve that one also
But we have not finish yet. If you think again what we did is export only the key of the PersistentApplication, but the key type is GUID meaning that the distributed application with the one from the which we are going to export will have different keys. To solve this one we have to go to the PersistentApplication Graph and change the key from Oid to UniqueName, thus IO engine will not get confused and will used the appropriate object
Step4 –Select and export models
Just go to a list view that has the objets you are interested to export and use the IO/Export action
Step 5—Import the exported objects
This process is very easy and only requires to use the IO/Import action and choose the xml file .