-
Notifications
You must be signed in to change notification settings - Fork 18
product optnios and variants
Magento allows customizing a product before adding the product to the cart. Customization happens through the customizable options defined by the merchant. Options can represent customization, other products, digital goods so on.
All Magento product types represented through the options.
- ProductOption - represents a product characteristic which allows editing before adding to cart. ProductOption has to have a label, information on how option values should be displayed, and is this option mandatory.
- ProductOptionValues - belong to a particular option as to a group and represent selections which allowed by the option. Option value could by display label, also one or may values could be pre-selected.
- ProductVariant - represent the final selection of one or multiple option values that will characterize the customized product in a shopping cart. Depends on the business scenario, a particular product variant could be linked with an existing product, with a price, or an inventory record, or no be linked to any. Even with no entities associated with the variant, it still has great value for a catalog because the presence of the variant says that such composition of options and their values described by the variant makes sense so that it can be purchased.
The application distinguishes two approaches to manage options:
Approach 1, "One to many": Multiple options selections lead a shopper to a selection of the single variation.
Example: configurable products
Approach 2, "One to one": The selection of multiple options leads to multiple product variants.
Examples: bundle product, customizable product, downloadable products.
Both of approaches could be used together.
Example: configurable product with customizable option.
During my research, I analyzed documentation on how options are covered by the competitors. commercetools and Shopify attack this domain with product variants that represent all the possible options. Despite the domain simplification by reducing the number of entities both systems constrained with the size of a product which makes it impossible to compose complex business cases that we frequently may face in the Magento ecosystem.
Commercetools: Modeling Products
Bigcommerce has a more complex option representation then Shopify or Commercetools (which is not weird due to a large number of Magento ex-employes employed by Bigcommerce nowadays). in some way, I would compare their options features with Magento 2 x functionalities. Bigcommerce segregates options from variants and allows to associate intersection of options with a new product, and as a result, I believe, struggles from the same disease as Magento does - redundancy in the variant data.
The great advantage of Magento 2 - modularity was not a real thing for the product options during Magento the lifetime. Since times of Magento 1.x option prices coupled into options, inventory records ignored even options with assigned SKUs. The only thing that had to play it together "Bundle" product was designed too complex to treat it as universal solution it had to become.
That's why, with the storefront project, we have an opportunity to resolve it.
Taking into account the Magento experience (good, bad, ugly) and solutions proposed on the market. I could define the set of requirements that I would want to see in a new options implementation:
-
Options are a predefined list of possible product customizations. This list belongs to the product exclusively; it is measurable, and limited only by the business requirements. So it always easy to return even a complete set of options for rendering PDP initially.
-
Variants are a unique intersection of one or may option values. The variant matrix does not belong to a product as property. The variant matrix is stored managed separately from products. The primary role of variants is to distinguish the possible intersections of options from impossible. The variants matrix is never meant to be returned to the storefront as is. The variants matrix will be used for filtering options allowed at the storefront after one or many options selected.
-
Variants could link the options intersection with a product, a price, or an inventory record but this is not mandatory.
As a result, we can design options/variants schema minimalistic.
syntax = "proto3";
message Product {
repeated ProductOption options = 100;
}
message ProductOptionValue {
string id = 1;
string label = 2;
string sortOrder = 3;
string isDefault = 4;
}
message ProductOption {
string id = 1;
string label = 2;
string sortOrder = 3;
string isRequired = 4;
string renderType = 6;
repeated ProductOptionValue values = 5;
}
message ProductVariant {
repeated string optionValueId = 1;
string id = 2;
}
Lets review pseudo SQL schema, which implements the picture described above. This is not the instruction for implementation, tables intentionally do not have all the fields of data objects. The example proposed to show the relations and operations that we have in the domain.
create table products (
object_id char(36) not null,
name varchar(128) not null,
primary key (object_id)
);
Table products
stores registry of products.
create table product_options (
option_id char(36) not null,
object_id char(36) not null,
label varchar(64),
primary key (option_id)
);
alter table product_options
add foreign key fk_product_options_object_id (object_id) references products(object_id);
Table product_options
- represents registry of characteristics that allows customization,
for instance, for apparel items, it could be "Color" and "Size".
create table product_option_values (
value_id char(36) not null,
option_id char(36) not null,
label varchar(64) not null,
primary key (value_id)
);
alter table product_option_values
add foreign key fk_product_options_product_id (option_id) references product_options(option_id);
Table product_option_values
- actual values that could be used to customize products, categorized by options.
create table product_variant_matrix (
value_id char(36) not null,
object_id char(36) not null,
weight tinyint not null,
primary key (value_id, object_id)
);
alter table product_variant_matrix
add foreign key fk_product_variant_matrix_value_id (value_id) references product_option_values(value_id);
product_variant_matrix
- Stores the correlation between option values and variants, by using this correlation, we can say which of option combination is real.
Field product_variant_matrix.weight
- says how many options should match to match the whole variant.
The following script models data from the picture above. Starting here I will use fancy values for primary keys instead of UUID to make further scripts more readable. I assume that the human eye cannot efficiently analyze tens UUID signatures.
insert into products (object_id, name)
values ('t-shirt', 'T-Shirt');
insert into product_options (option_id, object_id, label)
values
('color', 't-shirt', 'Color'),
('size', 't-shirt', 'Size')
;
insert into product_option_values (value_id, option_id, label)
values
('red', 'color', 'Red'),
('green', 'color', 'Green'),
('l', 'size', 'L'),
('m', 'size', 'M')
;
insert into product_variant_matrix (value_id, object_id, weight)
values
('l', 'l-red', 2), ('red', 'l-red', 2),
('m', 'm-red', 2), ('red', 'm-red', 2),
('m', 'm-green', 2), ('green', 'm-green', 2);
So far, all looks pretty nice with such an approach product may return information for all available options with the single request.
mysql> select p.name, po.label as option_label, pov.label as option_value_label
-> from products p
-> inner join product_options po on p.object_id = po.object_id
-> inner join product_option_values pov on po.option_id = pov.option_id
-> where p.object_id = 't-shirt';
+---------+--------------+--------------------+
| name | option_label | option_value_label |
+---------+--------------+--------------------+
| T-Shirt | Color | Green |
| T-Shirt | Size | L |
| T-Shirt | Size | M |
| T-Shirt | Color | Red |
+---------+--------------+--------------------+
4 rows in set (0.01 sec)
Let's assume that we have chosen one option value from the list. Starting this point we can look into variants to analyze remaining options. From the proposed example, we have chosen "Size": "M".
mysql> select object_id, value_id, weight
-> from product_variant_matrix
-> where value_id in ('m');
+-----------+----------+--------+
| object_id | value_id | weight |
+-----------+----------+--------+
| m-green | m | 2 |
| m-red | m | 2 |
+-----------+----------+--------+
2 rows in set (0.01 sec)
As you may see, our selection has matched two variants. Both variants have weight two, which means that we have to match at least two values to match the whole variant, but we used only one, which means that we can request the remaining options, that correspond to our current selection.
mysql> select p.name, po.label as option_label, pov.label as option_value_label
-> from products p
-> inner join product_options po on p.object_id = po.object_id
-> inner join product_option_values pov on po.option_id = pov.option_id
-> where p.object_id = 't-shirt' and pov.value_id in ('red', 'green');
+---------+--------------+--------------------+
| name | option_label | option_value_label |
+---------+--------------+--------------------+
| T-Shirt | Color | Green |
| T-Shirt | Color | Red |
+---------+--------------+--------------------+
2 rows in set (0.00 sec)
Note: To achieve more advanced behavior, the variants could be "uneven" inside the single product. For instance, you would like to track only t-shirts XL: size separately for some reason (a different price or stock). The example above focused on covering the main case scenario. Still, the approach, overall, is meant to support extending the logic of resolving option values onto a variant under the hood.
- Home
- Onboarding
- Development:
- Project agreements
- Time Off Tracking List
- Design Documents:
- QA
- Demo
- Contacts