
So here is a simple sample with some structural changes and the swap between HDBTABLE and HDBMIGRATIONTABLE. Lets start with a very simple definition:
Now we add some data into the generated tables:
Now we found out that the structure needs to be changed:
Instead of a Person_Name we need a Person_LastName and of course we now need additional a Person_FirstName. Now if we rename Person_Name the first name has be set into a different column and the old column has to be flashed. One could have done the renaming better but now you see for your cases new possibilities.
We will do this changes with HDBTABLEMIGRATION:
Step 1.) copy the original object, renamed it by adding ".TXT" and modified the extension of the copy to "HDBMIGRATIONTABLE":
Step 2.) Fill in the migrationstep and the new desired table structure in the copy
By this we change the OWNERSHIP of the design time object as well.
Step 3.) Deploy the project in BAS on the highest level. This will ensure "Auto undeploy" behavior.
Otherwise you have to maintain the undeploy.json file in your project.
What you see now in the deployment log:
The runtime object "PERSON" now has new OWNER.
And we got the migration right.
As a last step we have to get back to the HDBTABLE format.
So a copy of the migrationtable file, rename and cleanup leads to:
Note that you can "neutralize" HDI-Artifacts with rename "*.txt".
Now a new deployment that will change the ownership again:
now the new Person_aftermigration.hdbtable is the owner of the run time artifacts.
Complex changes on a HDBTABLE can be done with an intermediate HDBMIRATIONTABLE.
This does also work with HDBCDS. That is useful in migration scenarios from Hana on premise to HANA Cloud.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
14 | |
13 | |
12 | |
9 | |
9 | |
6 | |
6 | |
6 | |
6 | |
5 |