Table-Level Patterns
The patterns described in this section—the Find and Exists methods, polymorphic associations (Table/Group/All), and Generic Record References—apply to tables.
Find and Exists Methods
Each table must have the two static methods Find and Exists.
They both take the table’s primary keys as parameters and return the
matching record or a Boolean value, respectively. Besides the primary
keys, the Find method also takes a Boolean parameter that specifies whether the record should be selected for update.
For the CustTable table, these methods have the following profiles.
static CustTable find(CustAccount accountNum, boolean _forUpdate = false)
static boolean exist(CustAccount accountNum)
|
Polymorphic Associations
The Table/Group/All
pattern is used to model a polymorphic association to either a specific
record in another table, a collection of records in another table, or
all records in another table. For example, a record could be associated
with a specific item, all items in an item group, or all items.
You implemented the
Table/Group/All pattern by creating two fields and two relations on the
table. By convention, the first field’s name has the suffix Code, as in ItemCode. This field is modeled using the enum TableGroupAll. The second field’s name usually has the suffix Relation, for example, ItemRelation.
This field is modeled using the extended data type that is the primary
key in the foreign tables. The two relations are both of the type Fixed field relation. The first relation specifies that when the Code field equals 0 (TableGroupAll::Table), the Relation field equals the primary key in the foreign master data table. The second relation specifies that when the Code field equals 1 (TableGroupAll::Group), the Relation field equals the primary key in the foreign grouping table.
Figure 1 shows an example.
Generic Record Reference
The Generic
Record Reference pattern is a variation of the Table/Group/All pattern.
It is used to model an association to a foreign table. It comes in three
flavors: (a) an association to any record in one specific table, (b) an
association to any record in a fixed set of specific tables, and (c) an
association to any record in any table.
All three flavors of this pattern are implemented by creating a field using the RefRecId extended data type.
To model an association to any record in one specific table (flavor a), a relation is created from the RefRecId field to the foreign table’s RecId field, as illustrated in Figure 2.
For flavors b and c, an additional field is required. This field is created using the RefTableId
extended data type. To model an association to any record in a fixed
set of specific tables (flavor b), a relation is created for each
specific foreign table from the RefTableId field to the foreign table’s TableId field, and from the RefRecId field to the foreign table’s RecId field, like shown in Figure 3.
To model an association to any record in any table (flavor c), a relation is created from the RefTableId field to the generic table Common
TableId field and from the RefRecId field to Common
RecId field, as shown in Figure 4.
