Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Class rules - Understanding warnings

Updated on September 22, 2020

 This presentation is part of the Designing and Building for Performance Self-Study Course.

 

Transcript

A significant design time warning pertains to how the PRPC concrete classes that persist data are mapped to the underlying database tables.

A significant advantage of PRPC is the ability to create new concrete classes, add properties , and never involve the DBA in the day-to-day iterative development.  This allows the developer to focus on rules development, rapidly create the application, and test it for functional completeness without having to involve the DBA at each step to maintain a schema that matches the application.

PRPC’s default mapping of concrete classes is to one of four default (and very generic) tables:

  • PR_OTHER
  • PR_DATA
  • PR_HISTORY, and
  • PR_INDEX

These tables are bare bones and do not have exposed columns nor indexes to support your queries.

The class that holds the Home Codes data shows a warning. Rules can save as Valid; however, it may contain a warning.  Look to the bottom of the rule for the associated warning messages.

When new classes are created, by default they are mapped to PR_OTHER.  When the application is deployed, ideally no classes should be mapped to any of the four default tables.

You can remap concrete classes to database tables quickly and easily…

Using the class explorer, navigate to the Data-Admin-DB-Table instances, which show the mapping of PRPC classes to database table names. 

This mapping takes into account a form of pattern inheritance.  For example, a class named Data-Admin-XXX would map to pr_data_admin, yet a class named Data-MyRules-XXXX would map to PR_DATA.  If there are no matching mapping rows found, the mapping is assumed to be PR_OTHER.

To fix this problem, create a new instance row, such as “UServ-Data-HomeCodes”, and map it to a new database table, such as HomeCodes.

  • Have the DBA model this new table from PR_OTHER. Use PC_WORK if it was a work object table.
  • The developer can also create indexes if filtering is needed.

After the class is mapped and the DBA has created the new HomeCodes table, test that the connection to the new table is working properly directly from the class rule.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us