Posted: 22 Dec 2016 16:29 EST Last activity: 30 Jan 2017 10:50 EST
Reference Data Table Base Class
Attached and below is an idea for a base class that can be used by any Reference Data Table/Type.
Comments are welcome how this idea can be extended or improved.
In particular am looking for rules that can be applied to any Data Type that extends this base class.
Consistent definition of Reference Table base-class Properties to promote Rule reuse.
All reference Data Tables could share similar characteristics:
Permit different “list types” to be defined
Require the use of a unique, non-modifiable “code” for each item in a list – each code being synonymous with a distinctive pyLabel value which is allowed to be modified.
Allow each item in a list to be de-activated / re-activated
Provide a data-independent way to specify list display order
The solution is to define an inheritable, abstract base class.
Version * (optional)
* Key field indicator
** The IsActive property can be Y/N as opposed to true/false
Versionable data can be supported via a subreport that performs the following query:
Select Code, ListType, MAX(Version)
WHERE Version <= Param.MaxVersion
AND IsActive = true
The main report would inner JOIN to this subreport by Code, ListType, and Version match.
A different Report Definition would not be allowed to use a version-filtered Report Definition as a subreport since Pega does not allow subreports to be used beyond one level.
Purpose of the “ListType” Property:
A “ListType” Property fits well with the notion of Data Page “Keyed Access” per Help text below
Keyed Page Access
For list-structure data pages, you can allow read-only access to embedded pages in the data page, using any property or properties you want as the key. This permits significantly faster response when dealing with a large list.
Check the Access pages with user defined keys check box to allow read-only access to individual objects in the list based on the value(s) provided for the key(s).
Check the Allow multiple pages per key check box if the keys are not unique across objects in the list. This provides read-only access to a list of objects that match the value(s) provided for the key(s) in this case.
In the Page List Keys field, select at least one property as the page list key. You can add additional properties by clicking the + icon.
Hence to define different Lists based on a particular “ListType” you simply need to associate a “ListType” Parameter to a List Data Page that sources a Report Definition., e.g., D_ReferenceData[ListType:].
If you happen to have different “lists of lists”, extend Data-DataTableBase then add the new Key Property, e.g., ListType2, that distinguishes each “list of lists”. Then add a second parameter to the List Data Page associated to that class, e.g., D_ReferenceData[ListType:, ListType2].
Suppose additional “keys” per “ListType” besides “Code”?
Add those keys within your derived, concrete DataTable class then expose those additional key Properties as columns in your own table that is cloned from DATA_TABLE_BASE.
NOTE: every key in addition to “Code” adds another dimension to the data. EX:
Suppose 3 Code values for a particular list, say A, B, C
A second key is added as a qualifier. The 2nd key has 3 possible values, say D, E, F
The number of possible combinations of the two keys is :
3 x 3 = 9, i.e., 3 squared
Suppose a third key/qualifier is added with 3 possible values?
The number of possible combinations of the three keys is :
3 x 3 x 3 = 27, i.e., 3 cubed
Suppose additional “return values” per list besides pyLabel, IsActive, and SortOrder?
Add those additional “return values” to your derived, concrete DataTable class then expose them. You do not have to place everything in one table, e.g., DATA_TABLE_BASE. Create a new database table if it makes sense.
While is certainly possible to “get fancy” and define multiple generic “value” columns such as VALUE2, VALUE3, etc., and/or multiple generic “key” columns such as CODE2, CODE3, etc. - the “External Mapping” tab of the Class rule being used to define Property-to-DB-Column mapping – why bother?
Database storage should be transparent to Objects, i.e., Objects should have no idea, or care, how their information is persisted.
There is no requirement stating that multiple, non-compatible Data Tables absolutely must store their data within the same Database table.
Suppose a 1:M Tree Structure or Many-to-Many Relationships?
A 1:M relationship can established by extending Data-DataTableBase and then adding a “Parent” keys, e.g., ParentCode, ParentListType, and optional ParentVersion.
Suppose, however, a Product Catalog where it is desirable to navigate to the same Product via multiple Category paths, each Category possessing a “ParentCategory” Property.
A Data Structure that satisfies both use cases is to define a completely separate “Association” table as shown below.