Question

Advanced Tab Class Option - Propagate schema changes to child tables

On the advanced tab of the rule-obj-class ruleform, there is an option to "Propagate schema changes to child tables". This sets the .pyIsCoreClass property, which is referenced nowhere else in the system. There is no documentation around this option.

I've created a framework work class, and an implementation work class that direct inherits to it. On the framework class, I checked the "Propagate schema changes to child tables" checkbox. Then, I imported a product that triggered changes to the framework's db table. Nothing happened to the implementation work class's database table.

Does anyone know if this functionality is intended to work? It looks like it was added in 8.x. From what I can tell, the functionality is not yet fully flushed out. Does anyone know when it will be? The functionality would be very helpful if it works.

Comments

Keep up to date on this post and subscribe to comments

October 12, 2019 - 7:47am

Indeed no documentation. I have reached out to SME for insights.

October 19, 2019 - 12:56am

Anyone at Pega have thoughts on this?  I had created an SR posing the same question, but was told told that it was not something GCS would normally look in to.  Should I reopen the SR?

October 20, 2019 - 7:16am
Response to Jerome@quavo

Hi Jerome,

Below is the details that i could find on this;

The core tables for the platform are:

 

  • pr4_rule (Rule-),
  • pr_data (Data-),
  • pc_work (Work-),
  • pc_history_work (History-Work-)

 

Schema changes to the core tables are recommended to be propagated to child class tables for performance and/or usability reasons.

 

Regards,

Vikash

October 20, 2019 - 9:54pm
Response to Vikash Karn

Do you think then that the purpose of the "Propagate schema changes to child tables" actually means "changes to the core tables...pr4_rule, pr_data, pc_work, and pc_history_work should be propagated to self/current class"?  The wording of the checkbox label as it is today, feels like the intent is to make the current class's be considered a core table, and that changes to the current class's table would then be propagated to to its children.

October 21, 2019 - 12:29am
Response to Jerome@quavo

When the new application wizard is run to extend the FW layer, it creates equivalent case types by "direct-inheriting" from case types in the FW layer. The new application wizard used to clone the tables that are mapped to the FW layer case-types.

This option is provided to clone all the exposed columns (optimized for reporting) to the newly created tables as previously it didnt used to clone these columns.

October 28, 2019 - 9:04pm

It would be really slick if the checkbox triggered the implementation class tables to create/update the new columns when imported product rules caused those sorts of changes on the framework class's tables.