<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_SAP_Commerce_Cloud_Essentials_for_Develope_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2024-11-21T07:42:21.000Z

Analyzing Data Type Deployment

<div id="content"><p tabindex="0">Now that you understand the basics of the SAP Commerce Type System and how to use items.xml to configure and customize data types, the next step is to deploy custom data types to the SAP Commerce Cloud system.</p><p tabindex="0">The next video will describe the essential processes.</p><div class="kalturaVideoLessonWrapper"><div aria-label="This video explains the relation between Type System definitions and their respective deployment tables." class="kalturaVideoLessonContainer" data-testid="video" id="1_hhr8cotf"></div></div></div>

Data Type Deployment

Exploring the Technical Essentials of SAP Commerce Cloud

Using the information found in its combined items.xml file,  it creates or updates the necessary database tables  using the intitialization or update processes. For example, the out-of-the-box item type Product is persisted to the products table. If you modify the Product type to have a brand property,  then the table is modified to have a brand column when you next perform a system update.  What happens if you add a new item type that extends Product, say Car?  In this example, Car adds two Integer properties  to those it inherits from Product: horsepower and kilowatt.  It also adds a reference to an instance of the Employee type,  which it names ‘mechanic’. By default, an item type’s instances are deployed to its parent’s table,  which is extended with the necessary columns to store the subtype’s properties. In our example, the vehicle five Car instance is deployed to the products table,  which has been modified to have columns for horsepower, kilowatt, and mechanic.  The type system refers to the itemtype property  to determine whether a row belongs to Product, or to one of its subtypes.  So a Flexible Search query for Car entities will select all rows whose itemtype is Car. But a query for Product entries will return both Products and Cars,  since Cars are Products.  For more details on querying the type system,  such as how to return only items whose itemtype is explicitly Product,  please refer to the section on Flexible Search. But what if you wanted to store Car entities in their own table?  You could do that by adding a deployment tag to the item type’s definition in items.xml. The cars table created when you update the system  will contain the same colums as the products table,  plus columns for the properties specific to the Car item type.  In this situation, there will be no entry for vehicle five in the products table. Now, a Flexible Search query for Car entities will select rows from the cars table,  and ignore the produicts table.  But a query for product entries will return entities from both tables, following a union operation.  You should consider the performance implications of  deploying a subtype to its own table.  Using this example, if you have many subtypes of Product,  each deployed to its own table, and perform frequent Flexible Seach queries on Product, the type system could end up generating queries containing many unions,  which would degrade performance.  But if you only ever query the subtypes,  deploying them to their own table could save space on the database. Now let’s see what get stored in these tables. The values of atomic type properties will be stored directly in the table cell. For example, a string is stored as a varchar, as defined in the java.sql package. But what about references to other types? I’m looking at you, mechanic! As we saw earlier, the mechanic property is a reference to an entity of type Employee. The Employee type is a subtype of User, and is deployed out-of-the-box to the users table. Like every entity in the type system,  the row for the employee named Antoine Lavoisier has a column named PK,  which stands for Persistence Key. That persistence key is stored in the mechanic column of the cars table  to link vehicle five to its mechanic. Another way to establish a reference between type system entities is through a relation. Let’s say we have two employees assigned as the drivers for one of our cars, Henri and Sophie.  We may have a number of cars available, each with a unique persistence key. When we define a one-to-many relation between Car and Employee,  so that each employee may drive one car, a column named car is added to Employee.  It will contain persistence key references to the car being driven.  In this case, Henri and Sophie both get a reference to the Citroën they drive. When it comes time to find the drivers of the Citröen,  the type system queries the users table  for users whose car column value matches the Citroën’s persistence key value.  Here, two employees are returned. Now let’s consider the deployment of a many-to-many relation.  We start with the same cars table, but this time we’re interested in Employees To have reviewed one or more cars.  Our reviewers here are Oscar and Mary.  We define a Car2Reviewer relation,  consisting of many Employees reviewing many cars.  To maintain the integrity of the relation, the type system needs to define a link table. That means a deployment tag is mandatory for many-to-many relations. The table created has two columns. Each pair of values it contains is unique. If we consider our reviewer Oscar,  the link table informs us that he’s written two reviews,  one for the Ferrari, and one for the Citröen. And if we look at the Citröen, we can see that two reviewers have penned a review for it, Oscar and Mary. Earlier, when we gave the Car item type a deployment table,  we assigned a typecode to it.  This typecode is required to uniquely identify a deployment,  for example when caching query results.  A type code is a number between zero and 32,767.  Which is two to the fifteenth minus one. It’s important that no two deployments use the same typecode. SAP Commerce reserves the first ten thousand codes,  and some extensions reserve blocks of one hundred codes. You should always keep a registry of the typecodes you’ve used in your project  so you don’t accidentally reuse one.  There may be exceptions to the list you’ve just seen,  which you can find in the SAP Commerce help pages.  Better yet, take a look at the following file for a full list of exceptions. Collections of atomic or reference types are stored as comma-separated lists  of atomic values or persistence keys.  For example, if Car has references to a collection of strings  and to a collection of country items,  each one is stored in a column as a comma-separated list.  String values for the first, PK references for the second.  Finally, recall how a new item type is by default deployed in its parent type’s table.  In our example, in the absence of a deployment tag,  the Car item type is deployed in the table for its parent, products.  But what happens if we didn’t provide a deployment tag for Product?  Any type that doesn’t specify a parent type automatically extends GenericItem.  So if Product lacked a deployment tag, it would be stored in the GenericItem table.  This approach would be inefficient both from a storage space and performance point of view.  That’s why we strongly recommend that direct subtypes of GenericItem  always specify a deployment table.  We feel so strongly about this that SAP Commerce’s development mode includes a setting that will throw an error if you  forget to deploy a type that directly extends GenericItem.