Polymorphism: How Pega acts on instances that are runtime subclasses of their design time type [LSA Data Excellence]
Can you clarify how Pega acts on the runtime type of an instance when it is a subclass of the class used at design time? For example, when saving that instance, what table does it get saved to?
At runtime, all behavior is determined by the runtime type of the instance, on the expectation that it is the same type - or a subtype - of the class specified at design time.
Consider a Section XYZ referenced from a Flow Action whose Applies To class is MyOrg-MyApp-Work-ABC. For the Flow Action to be design-time valid, XYZ must at least be defined on class ABC.
When an instance of MyOrg-MyApp-Work-ABC-DEF reaches that Flow Action at runtime and looks to show the UI, Rule Resolution starts from DEF when seeking the Section rule named XYZ.
- If XYZ has been class-specialized into DEF, Rule Resolution returns the DEF specialization which allows a DEF-specific rendering of the XYZ view (perhaps showing values for properties defined on the DEF class);
- Otherwise, Rule Resolution proceeds to traverse DEF's inheritance hierarchy, finding an XYZ Section defined on ABC.
Similarly, when saving an instance to the Pega database, the runtime class of the instance being saved drives the lookup of Database Table instances. From the ABC/DEF example above:
- If DEF had its own Database Table instance, the instance is saved in the DEF-specific database table;
- Otherwise again DEF's inheritance hierarchy is followed until a Database Table instance is matched to yield the table in which the DEF instance is stored.
Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.