Posted: 17 Mar 2016 9:06 EDT Last activity: 6 Apr 2018 19:26 EDT
Running the update scripts separately for rule schema and data schema
For a normal upgrade/update, we would normally follow the below steps as stated in the upgrade/update guides :
1)Migrate existing rule schema to the new rule schema using the migrate script.
2)Run the update/upgrade script by setting specific properties in the setUpdatabase.properties file.
3)Run the migrate script again to generate the rule schema objects.
4)Run the update/upgrade script to update the data schema by passing the data only parameter.
For Step 2,PEGA suggests to configure the setupDatabase.properties file by specifying the name of the Rules schema for both the rules.schema.name and the data.schema.name properties. If we specify the data schema in data.schema.name and run Step 2, what’s the difference in the scripts applied on the data schema as compared to if we run the update on the data schema with the data only parameter ? If step 2 is executed by mentioning rule and data schema names in the setup database files , is there any need to run step 4? What's the difference in the scripts that are executed in the database for both the cases?
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
After migrate when you are running the upgrade you have to give rules.schema.name and data.schema.name properties with the same RuleSchema name, but in case of Data upgrade you have to give rules.schema.name and data.schema.name properties with respective rules and data schema names .
That's exactly what my query is..What happens if we specify the rule and data schema name while running the upgrade post migration? What's the difference between doing what i said and running the data schema upgrade separately?
While running step 2.. rule.schema.name and data.schema.name will be the new schema. At this point, entire rulebase will be upgraded
While running step 4, rule.schema.name will be new schema and data.schema.name will be 5.x/6.x schema. In this step , the 5.x/6.x schema will become pega 7 data schema and only data related upgrade tasks will be executed.
I think I am not being able to put across the point correctly. What you have mentioned is what is recommended to be done but what will happen if we mention the data schema name while running the update script post rule migration and not execute the step where the update script has to be run only with the data only parameter.
The reason I am asking is because as part of a POC we have upgraded the AES where in we have not executed step 4 of upgrading data schema separately. We have mentioned the data schema while running the update script in step 2 which is meant for the rule update post rule migration and it seems that it has worked out just fine.
Hence we wanted to know if this is a valid way of proceeding with the upgrade before we start upgrading the main PEGA instance.
These 4 steps are provided because rulebase upgrade may take hours and your system need not be down the whole time but only the duration of data upgrade.
If I understand correctly, what you are asking is, after migration you will run the upgrade with new rules schema and the old schema as data schema. Yes, theoretically that approach will work with the only caveat being there will be downtime for entire upgrade. Please note that this approach is not recommended as per Pega Upgrade guides.
I have a question here. Got your point with respect to a upgrade project from say Pega 6 to Pega 7. But now say for an in-place update from 7.1.8 to 7.2.2 (where we already have defined split schema), when Rule upgrade is running on the current rules schema, is there any harm if we mention the appropriate data schema as part of step 2?
If you want to do 718 to 722 update and you are ready for a minimal downtime then you can run step 2 directly with appropriate rule and data schema. There is no need for any migration or separate data update .