Announcement: You can find the guides for Commerce 7.5 and later on the new Elastic Path Documentation site. This Developer Center contains the guides for Commerce 6.13.0 through 7.4.1.Visit new site

This version of Elastic Path Commerce is no longer supported or maintained. To upgrade to the latest version, contact your Elastic Path representative.

Extending the Domain Model

Extending the Domain Model

The Elastic Path Commerce platform is built on a flexible e-commerce domain object model. If your organization has specific needs, you can extend it. Changes to the domain object model affect the platform on many levels, both in terms of functionality and performance. Before making domain changes, you need to carefully consider the impact.

  • Be aware of how Load tuners and FetchGroups optimize the loading of fields for different types of objects.
  • If you are thinking about extending catalog-related domain objects (Product, Catalog, etc.), consider whether you can use attributes instead.

The basic steps for extending the domain object model are:

  1. Modifying the database schema
  2. Creating the domain class and interface
  3. Modifying the ORM configuration
  4. Add references to the Persistence Unit
  5. Registering it with the BeanRegistrar
  6. Enabling bytecode enhancement

Modifying the database schema

When creating or modifying a domain object, you need to extend the database to store the new data.

If you are creating a completely new domain object, you will need to add a new table.

If you're extending an existing domain object, we recommended that you use the joined inheritance strategy. With this strategy, the base class's data is stored in the base table and your extended class's data is stored in another table. To implement this, you need to:

  1. Add a table to store the extension class's data.
  2. Add a discriminator column in the base domain object's table. This discriminator column is used by the persistence layer to identify, for each row, which table contains the row's extended class's data field.

For an example on how this is done, refer to step 2 of Core Tutorial 3.

Domain classes and interfaces

Any new or extended domain object has both an interface defining the methods and a class containing the implementation. To ensure the domain object's data is persisted and loaded correctly, the implementation class need to contain the appropriate JPA annotations. At a minimum, you need to include:

  • @Entity and @Table annotations at the class level.
  • @Basic and @Column annotations on the getter methods to specify how field data is mapped to table columns.
  • Annotation required to load data from related tables (e.g., @OneToMany, etc.)

If you're extending an existing domain object, you'll also need to set the value that will be stored in the base table's discriminator column.

The following code snippet shows the table annotations for an extension of the OrderImpl class.

@Entity
@Table(name = ExtOrderImpl.TABLE_NAME)
@DiscriminatorValue("extOrder")
@PrimaryKeyJoinColumn(name="UIDPK", referencedColumnName="UIDPK")
public class ExtOrderImpl extends OrderImpl implements ExtOrder {
    ...
    public static final String TABLE_NAME = "TORDEREXT";

For more information, see the OpenJPA documentation on metadata mapping.

Modifying the ORM configuration

If you're extending an existing domain class, JPA needs to be made aware that the base class accepts extensions. This means overriding the JPA metadata for the base class.

Metadata files are located in core\ep-core\src\main\resources\META-INF. For an example of how to extend or override them, refer to step 3 of Core Tutorial 3.

Add references to the Persistence Unit

New persistence classes and metadata ORM files should be registered in the core extension's jpa-persistence.xml, which is located in ext-core/src/main/resources/META-INF. For an example of how this is done, see step 3 of Core Tutorial 3.

Registering new domain classes with the BeanRegistrar

New domain classes must be registered through the core bean factories. You can add new bean definitions in the core extension's ep-core-plugin.xml to include entries for the new classes.

For an example on how this is done, refer to Replacing Core Beans in step 1 of Core Tutorial 3.

After you make this change, running mvn clean install from the command line against the core extension project will compile your classes, perform bytecode enhancement, rebuild the jar, and install it in your repository.

Enabling bytecode enhancement for custom persistent classes

Most domain classes contain data that needs to be persisted, and all persistent classes need to be bytecode-enhanced. This requires the Maven enhance plugin. For more information, see Enhancing core library extension classes. Once this is done, the enhancer will be invoked automatically during the process-classes goal in the package phase of the Maven build.

Exclude references from the Persistence Unit

To exclude existing domain classes and/or metadata ORM files, you can add to the exclusion lists persistenceMappingExcludedClasses and persistenceMappingExcludedFiles respectively. These can be found in the core extension's ep-core-plugin.xml file.

Override Persistence Unit Properties

Occasionally you may wish to override some of the properties defined in the core persistence unit, or add new properties. To do so, add the properties to the persistencePropertyOverrides map in the core extension's ep-core-plugin.xml file. Do not add or change properties in any of the jpa-persistence.xml files, as the order in which these files are resolved cannot be guaranteed.