When do you need to use a deployment table?
All items that don't have a deployment table are stored in the genericitems table. It makes the genericitems table extremely large. This makes the database work inefficiently causing performance issues.
Need to define a deployment table for all item types that extend GenericItem except abstract item type.
When you can’t use a deployment table?
When Item Types already has a deployment inherited from a supertype. Technically it's possible but is not recommended because you will get performance issues because the supertype requires a UNION clause with a new table.
What deployment type codes can you use?
<itemtype code="UrlPolicy">
<deployment table="UrlPolicy" typecode="18703"/>
<attributes>
<attribute qualifier="symbolsToReplaceRegex" type="java.lang.String">
<persistence type="property"/>
<modifiers read="true" write="true"/>
<description>Some attribute</description>
</attribute>
....
</attributes>
</itemtype>
If you don't want to have problems in the future use type codes larger than 10000. Because the Hybris platform uses type codes from 0 to 10000.
What types of relations are required a deployment table?
If a many-to-many relation does not have a deployment table, it's data stores in the links table along with the data from all the other many-to-many relations that don't have a deployment table. Of course, you will get serious performance problems.
How many values can a boolean attribute store? Should you define it?
A Boolean attribute can store 3 values - true, false, null. So, you need to define a default value for the Boolean attribute if you want to avoid problems with NullPointerExceptions.
// Potential NPE
if (product.isSpecial()){
someService.doSomething();
}
What are the requirements for item types names and attributes?
Item type Names should start with an uppercase letter
Item type attributes should start with a lowercase letter.
qualifier names should start with a lowercase letter.
Don't start Item type names with Generated, for example, GeneratedUserQuery - it reserved for Hybris abstract classes.
Should we use a relation that has cardinality='many' with attribute ordered=true, or it is a bad practice?
An option ordered='true' on any side of a relation that has cardinality='many' has a significant impact on performance when reading and writing from the database. Hybris build very complex queries to provide a defined order to the items that are much more complex and expensive than an unordered query.
What type of collection recommended to use for a relation that has cardinality='many'?
You have to use collectiontype='set' on any side of a relation that has cardinality='many' where items must not appear in that relation multiple times.
Should CatalogVersion attributes be unique for Catalog aware types?
Yes. Because the CatalogVersion attribute forms part of the unique key for Catalog Synchronization. Otherwise, you'll spend Friday night debugging.
Do we need to define database indexes for the unique attributes of type? Will this help us avoid duplicates?
The only database can guarantee no duplicates. The validation of the unique attributes in the Service Layer cannot entirely guarantee that there won't be duplicate records in the database.
So, you have to define database indexes for the unique attributes of the type.
What’s wrong with having a catalog aware type on the “many side” of a one-to-many relation?
You'll get an issue when synchronizing. The reference to the Catalog aware type will be transferred from the Staged to the Online version. The Staged version will no longer have a reference.
When do we need to have unique attributes for all types?
Always. All types should have unique attributes. This allows avoid duplicates and ensure import/export by IMPEX.
When do we need to use unoptimized attributes?
Never. Option dontOptimize="true" allows storing the data for this type in a secondary table defined by the propertytable attribute of the deployment or the props table if no propertytable is defined. hybris builds complex and expensive queries to handle it.
When do we have to create a new sub-type and when have we not?
We should extend the existing type when:
- Need to add a new attribute for all instances We should create a new sub-type when:
- Need to add a new attribute for specific instances
- Need to redeclare an existing attribute (for example change mandatory to optional)
What should we do with unnecessary indexes?
We should remove unnecessary indexes. Indexes should only exist for attributes used in flexible searches. Hybris creates a significant number of database indexes that many projects never use and those indexes slow down the writing to the database.
How often do we need to use collections in items.xml?
Collection types can cause truncation issues, so we have to use relations instead.
Can we change attribute definitions?
Sure, but the modification of an attribute qualifier has serious consequences on a system update.
A change of upper/lower spelling will change the signature of generated getters/setters, so it will cause API incompatibilities.
A change of spelling is the same as removing the attribute from items.xml and defining a new one with a different name. The old data is not accessible anymore by generated API.
A change of type. If the database does not support changing the type, changing the attribute type will not change the database schema. Nevertheless, the generated API will be changed, resulting in incompatibilities and a high probability of exceptions at runtime.
The modification of attribute type in redeclaration mode can throw a build error in case of incompatible type hierarchy (for example type of attribute was from String to Long).
Modification of columntype (subtag of persistence type) will succeed if the type is compatible on the database level, otherwise, no effect happens.
With the modification of attribute modifiers, you could get API incompatibilities due to the read and write flag influences code generation.
All other modifier modifications will cause different behavior which can be serious too and must be checked in detail. (for example: adding a unique flag can cause inconsistent data).
Can we change deployment code or table names?
Changing deployment code has fatal consequences. If you change the table name, you get a new table, and you lose access to the old data. It's because the typecode specified in a deployment tag forms part of the PK of the items inside the database. It helps find items very quickly by their PK because the typecode points directly to the correct database table. If you change a typecode for a table then all old items inside the table will not be found anymore and are lost with it.
Can we change a type declaration?
You should not change a type declaration because modifying the values of an existing itemtype tag will result in API incompatibilities between the two versions. This breaks backward compatibility and makes upgrades harder.
How can we improve the performance of large impex import?
You can define a database index on the lookup value of reference types for using it in IMPEX-import for example.
Follow me on my tech blog and telegram
Top comments (1)
you can write your experience on blogs.sap.com