Native attributes are persistent attributes which directly map onto columns in the database table represented by a persistent object (PO). They are part of the object model of the PO. Native attributes are stable, which means that they cannot be created nor can their definition be modified at runtime. Therefore, native attributes are primarily used to model attributes which every instance of a PO is supposed to possess.
Native attributes are not localized. Attributes that are subject to localization have to be modeled as extensible object attributes.
For each native attribute, Intershop Studio creates a pair of attribute accessor methods: a method to read, and a method to set the attribute value (unless the attribute modifier
readonly has been set to true, see below). These methods always have the signature:
AttributeType getAttribute() void setAttribute(AttributeType aValue)
Attribute designates the name of the attribute in the object model, and
AttributeType the attribute's data type.
In Intershop 7, various type conversions are performed for the attributes of persistent objects.
The respective mappings for supported data types are listed in the following tables:
Attribute of Primitive Type Mapping:
Attribute of Object Type Mapping:
In addition, there are some complex types that are mapped to artificial names in the object model. The complex types consist of one or more attributes that are mapped again according to their type.
Mapping of Complex Types
When modeling a PO, it is often impossible to predict which attributes each particular instance of the PO requires. Moreover, certain attributes may be relevant for a certain subset of PO instances only.
For example, with respect to the CAPI object
Product, an attribute like
Color may be relevant for clothing, but less relevant for books. Therefore, additional attributes may have to be added to a PO at runtime, depending on the exact usage of the object.
The base class
ExtensibleObjectPO provides a wide range of methods to add extensible object attributes at runtime, and to read and modify these attributes and attribute values later on.
Consider the following two methods made available by
void putString(String aName, String aValue) void putInteger(String aName, Integer aValue)
Calling the first method creates a custom attribute with the first parameter defining the name, e.g.,
Color, and the second parameter setting the attribute's value, e.g.,
red. The second method works similarly, except that the attribute is of a different data type.
put method, a corresponding
get method exists which is used to retrieve the value of an extensible object attribute, passing the attribute name as parameter.
String getString(String aName) Integer getInteger(String aName)
Besides using these general methods for attributes which are unknown at design time, it is possible to define extensible object attributes directly in the object model. For extensible object attributes defined in the object model, Intershop Studio generates the standard set of getter and setter methods, such as:
String getDescription() Integer setDescription(String aValue)
To store extensible object attributes, each PO based on ExtensibleObjectPO is associated with a special PO implementing
For example, the PO
WarehousePO is associated with the PO
WarehousePOAttributeValuePO, which implements
The associated attribute-value PO is also a persistent object.
WarehousePOAttributeValuePO maps onto a special table storing all extensible object attributes defined for the
Each instance of a class derived from
AttributeValue represents an attribute of a specific type with a specific value belonging to a specific instance of an
ExtensibleObjectPO. Going by example, each custom attribute-value pair defined for a particular warehouse is stored in its own instance of
WarehousePOAttributeValuePO, thus mapping on a particular row in the underlying database table. The Intershop Studio automatically generates the necessary
AttributeValue classes where necessary.
Extensible object attributes are not stored in the database table underlying a particular persistent object. Instead, extensible object attributes are stored in a separate attribute-value table which is associated with the main table of the persistent object.
Some persistent objects do not store their attributes in a separate attribute-value table. They store their (localized) attributes in the same table using a special XML structure instead. This concerns the objects
ConfigurationParameterPO. Commonly these objects extend
XMLExtensibleObjectPO instead of
ExtensibleObjectPO, and they are initiated by the
XMLCustomAttributeMgr during server startup. In this case the attribute values are stored in the columns
ATTRIBUTES (non-localized) and
ATTRIBUTES_<LOCALEID> for each available locale.
Attribute values sometimes have to vary as a function of the locale used. Localizable extensible object attributes provide the necessary mechanism.
Like extensible object attributes, localizable extensible object attribute can be defined directly in the object model. As a consequence, Intershop Studio generates the following
set methods (assuming a string attribute
void setDescription(String aValue, LocaleInformation aLocale) void setDescription(String aValue)
The first method allows you to supply a locale along with a value for
Description, tying the value to this particular locale. The second method automatically binds the attribute value to the current request locale (if defined) or to the lead locale (fallback). A similar logic applies to the
get methods generated by Intershop Studio.
For extensible object attributes not specified in the model, a similar mechanism exists, based on the following methods:
void putString(String aName, String aValue, LocaleInformation aLocale) void putString(String aName, String aValue)
The first method creates an attribute with a particular name and a particular value specific to a particular locale. The second method creates an attribute-value pair bound to the lead locale.
Localizable extensible object attributes are also always represented as instances of
Non-localizable attributes are attributes that are meant to have the same value in all locales.
Although non-localizable attributes do not have a locale assigned, they are stored for the lead locale ID in the separate attribute-value table which is associated with the main table of the persistent object. In case a lead locale switch has to be performed, all non-localizable attributes will be updated to the new lead locale by the
Replicated extensible object attributes combine the properties of native attributes and extensible object attributes. This mechanism creates attributes which are generated as part of the PO, and which are replicated inside the PO's
AttributeValue table. This setting is used for native attributes which should participate in the search mechanisms that operate on
Data types you can use for extensible object attributes include:
Like the extensible object attribute mechanism, direct custom attributes (DCA) provide a way to enhance existing POs with additional attributes. With respect to object-relational mapping, however, direct custom attributes behave much like native attributes. Direct custom attributes are mapped onto core table columns of the PO to which they are added. They are not stored in the associated
AttributeValue table. This may increase performance, e.g., when using these attributes as conditions in database queries. Because the attributes are stored directly in the database table underlying a PO, executing a query using these attributes does not necessitate table join operations between the PO's core table and the associated
The direct custom attribute mechanism is supported by the Intershop 7 import/export framework.
The following restrictions apply to direct custom attributes:
DCAs cannot be added or modified at runtime. Adding DCAs requires calling an ALTER TABLE statement. The ALTER TABLE statement must consider staging environments.
The following example of an SQL block adds a column to table
begin staging_ddl.add_column('BASICPROFILE', 'MYCOLUMN', 'VARCHAR2(100CHAR)'); end; /
The first parameter denotes the table name, the second parameter the column name, and the third parameter the column definition. The stored procedure checks internally whether a staging environment exists and calls the required
commands accordingly. You can execute the SQL block either manually from an SQL console or as part of a script file that is called by the SQLScriptPreparer.
Direct custom attributes are defined using simple XML-based descriptions. All attribute definitions contributed by a cartridge are declared in the directCustomAttributes.xml descriptor file. The name of the descriptor file is fixed. During cartridge development, the file is located in <IS_SOURCE>/<cartridge_name>/staticfiles/cartridge. When the cartridge is deployed on a system, the file is installed in the directory _<IS_SHARE>/system/cartridges/<cartridge_name>/release_.
These are all elements involved in configuring direct custom attributes in a directCustomAttributes.xml file:
entity element embeds
<classname> and one or more
<classname> element of the owning
primary-key = false
required-attribute = false
null-allowed = true
optimistic-control = false
Specifies the data type of the attribute. See the table below for details.
DCA types and JDBC mapping:
Direct custom attributes can be accessed using the
put methods made available by
ExtensibleObject, such as:
void putString(String aName, String aValue) void putInteger(String aName, Integer aValue) String getString(String aName) Integer getInteger(String aName)