To store the values of backing map properties, there must be a set of associated tables. The Oracle Commerce Platform database schema includes a set of tables for storing the values of backing map properties. The table used to store a given value depends on the backing map property being stored (which is determined by the data type of the value, as discussed in the previous section):
das_dyn_prop_map_str
– storesatgDynamicPropertyMapString
propertiesdas_dyn_prop_map_big_str
– storesatgDynamicPropertyMapBigString
propertiesdas_dyn_prop_map_double
– storesatgDynamicPropertyMapDouble
propertiesdas_dyn_prop_map_long
– storesatgDynamicPropertyMapLong
properties
Each row of a backing map table stores an individual property and its value in a format that facilitates storage and retrieval. The row contains:
The repository ID of the item
A string that identifies the dynamic property
The property value
The identifier string has the following format:
repositoryPathName
_itemDescriptorName
_propertyName
For example, the identifier for a weightInGrams
dynamic property of the product
item descriptor would be:
/atg/commerce/catalog/ProductCatalog_product_weightInGrams
Tables for Item Descriptors with Multi-Valued IDs
The tables listed above can store backing map properties for item descriptors with single-valued IDs (that is, descriptors that require only one ID column in database tables). For item descriptors with multi-valued IDs, backing map properties must be stored in tables with multiple ID columns.
To store backing map properties for descriptors that require two ID columns, additional tables are provided in the Oracle Commerce Platform database schema. These tables include columns named ID1
and ID2
for storing the IDs, and the table names are distinguished from the single-ID ones by the addition of the suffix _2
:
das_dyn_prop_map_str_2
das_dyn_prop_map_big_str_2
das_dyn_prop_map_double_2
das_dyn_prop_map_long_2
If you want to create dynamic properties for item descriptors that require three ID columns or more, you will need to create additional backing map tables. These tables must follow the same naming convention shown above, with the suffix indicating the number of ID columns. For example, if you add a descriptor that requires four ID columns, you must create tables with names having the suffix _4
. Each table must have four ID columns named ID1
, ID2
, ID3
, and ID4
.
If you add an item descriptor that you do not intend to create dynamic properties for, you can avoid having to create additional backing map tables by setting the descriptor’s skip-backing-map-generation
attribute to true
. See Backing Map Properties.
Repository-Specific Tables
The default backing map tables can be used to store dynamic subtypes and properties for any repository for which they are enabled. Because each row identifies the repository pathname and item descriptor it applies to, the same set of tables can be used for any number of item descriptors and repositories. This flexibility is especially convenient while developing applications. However, if you use dynamic item types and properties extensively, it is more efficient to have tables that are dedicated to a specific repository or even an individual item descriptor.
The repository definition XML for the backing map properties is generated automatically when the repository starts up. You can configure the repository so that the XML generated for different item descriptors refers to different sets of backing map tables. The logic for storing values of dynamic properties of a specific item descriptor is as follows:
If there is a dedicated set of backing tables for the descriptor, use that set.
If there is no dedicated set of backing tables for the descriptor, but a repository-specific set exists for the repository containing that descriptor, use the repository-specific set.
If there is no dedicated set of backing tables for the descriptor, and no repository-specific set exists for the repository containing that descriptor, use the global tables.
In addition to the global tables, the default Oracle Commerce Platform schema includes several other sets of backing tables: a set for the content management repository, a set for the product catalog, and a set exclusively for the sku
item descriptor. These tables are provided because of the potentially high volume of data associated with dynamic properties for these repositories and especially for the sku
item type.
If you use a separate set of tables for a specific repository, these tables must have the same names as the default set of tables, except the das
prefix in the names should be replaced with a repository-specific prefix. The prefix is specified using the defaultBackingMapTablePrefix
property of the repository component.
For example, the defaultBackingMapTablePrefix
property of the content management repository is set to wcm
, and the backing tables for this repository are:
wcm_dyn_prop_map_str
wcm_dyn_prop_map_big_str
wcm_dyn_prop_map_double
wcm_dyn_prop_map_long
If defaultBackingMapTablePrefix
is null (the default), the repository uses the global backing map tables.
For tables used for a single item type, the prefix is specified in the repository definition file using the backing-map-table-prefix
attribute of the item-descriptor
element. For example, the defaultBackingMapTablePrefix
property of the product catalog repository is set to dcs
, and by default most of the item descriptors in the repository use the backing map tables whose prefix is dcs
. The sku
item, however, uses its own set of tables that is specified in the repository definition file:
<attribute name="backing-map-table-prefix" value="dcs_sku"/>
A prefix specified in this way overrides the defaultBackingMapTablePrefix
setting for the individual item type only.
Note that the item descriptors in the content management repository and product catalog repository all have single-valued IDs, so the backing map tables supplied for these repositories do not include multiple ID columns. If you add a descriptor with a multi-valued ID to one of these repositories, you must add the necessary tables to the database schema. See Tables for Item Descriptors with Multi-Valued IDs for more information.