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 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.
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.
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.
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
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.
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.
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.
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.
Always. All types should have unique attributes. This allows avoid duplicates and ensure import/export by IMPEX.
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.
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)
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.
Collection types can cause truncation issues, so we have to use relations instead.
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).
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.
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.
You can define a database index on the lookup value of reference types for using it in IMPEX-import for example.
Created based on official documentation