The name came from Object Attribute Value, refering to the table that usually store the values.
While modeling a GenexusTransaction , the developer knows the attributes the Transaction has. But sometimes isn't possible to define some of the attributes at design time, usually because this information varies a lot. So the intention of this pattern is to define a mechanism to define and store information about a Transaction at run-time without changing the DB.
For example in People And Organizations Knowledge Base one can define any kind of data to store about People without changing the DB (eye's color, favorite soccer team, etc.). See Laura's characteristics.
Starting from a given Transaction, it creates the set of objects needed to handle this case.
Example: OAV for Customer.
Customer // Original transaction
Two new transactions will be needed:
CustomerAttributeValue // This is the OAV table
CustomerAttribute // Defines the set of valid attributes for Customer
CustomerAttributeCategory // used to order the attributes when many attributes are expected
Aditionally, the following functionality can also be included:
- Procedures to read and write a customer's attributes.
- "Enumerated" attributes (for use in comboboxes).
- A webpanel and/or workpanel for displaying these attributes (actually, the WW pattern can be applied here).
- A webpanel and/or workpanel for editing these attributes.