When and why are the attributes `propertyIds` and `categoryIds` in the product-response - shopware6

Question

I am doing a simple search on some products using the api-endpoint {{endpoint}}/api/search/product. What i sometimes see is that there are some products, where the attributes propertyIds and categoryIds are null, while there are sometimes products where these properties are not null.
However: All the examples have actual categories and properties assigned and are visible through other attributes.
My question is: What is the reason for this and how do this values get populated?
"minPurchase": 1,
"purchaseUnit": null,
"referenceUnit": null,
"shippingFree": false,
"purchasePrices": null,
"markAsTopseller": null,
"weight": null,
"width": null,
"height": null,
"length": null,
"releaseDate": null,
"ratingAverage": null,
"categoryTree": null,
"propertyIds": null,
"optionIds": null,
"streamIds": null,
"tagIds": null,
"categoryIds": null,
"childCount": null,
Example for one with Ids:
"b8a475de8b284e17b0ff4dba3729deff"
],
"propertyIds": [
"2c3257b006e240369ab32334096bca40",
"521eab63f64a47ae9f51801d57b4a0ae",
"6322d1a7de254bec8fe813d4dae43e97",
"8253d82499b44fdfbcea4f0238ba3258",
"a8c03127e8644749814ee6ca0f71cba7",
"b5b467f25ff3402ebbd4264b785153ec",
"d37c8640fd43427795365dae9cb750da"
],
"optionIds": null,
"streamIds": null,
"tagIds": null,
"categoryIds": [
"4c84f6cacaa7417fa18524d78156c9e4",
"b8a475de8b284e17b0ff4dba3729deff"
],
"childCount": 5,
"customFieldSetSelectionActive": null,
"sales": 0,

Answer 1

Both attributes propertyIds and categoryIds contain the IDs of assigned properties (such as color, size, material, etc.) and categories (a structural element used to group products in our navigation).
When one of those fields is null in a product, it simply means that no category or property is assigned to the product.
If you want to read the specific properties of categories of a product, the IDs are useless of course - but sometimes, you just need the ID to build a reference or a link.
If you want to see the actual properties and categories, you specify it in the request body as associations:
// POST /api/search/product
{
"associations": {
"properties": {},
"categories": {}
}
}
Another useful use case for *Ids fields are multi-assignments:
// POST /api/_action/sync
[{
"action": "upsert",
"entity": "product",
"payload": [{
"id": "0b3db9fe80af4d2bb81ecd649983a648",
"propertyIds": [
"13bc59c320a2400ea8d841da15f7b0f8", // Size: XL
"2fbb5fe2e29a4d70aa5854ce7ce3e20b", // Color: red
"0060b9b2b3804244bf8ba98cdad50234" // Material: cotton
]
}]
}]
Also see Bulk Imports

Answer 2

In Shopware there's the concept of indexing frequently read but rarely written data. This may for example be the count of variants for a product or, what you were wondering about, the IDs of associated entities. The indexed data is then updated whenever you update the entity, e.g. the product.
The idea is that unless you update the entity, that indexed data would never change and it is therefore safe to store it right with the entity in its table.
Let's say you then want to evaluate if a product has more than a certain count of variants, is part of a category or has certain properties. Then, instead of doing executing costly database queries to count rows or having a bunch of SQL joins to associated data, you can use these pre-indexed fields for your evaluation.
If you think that you're missing some data that should've been indexed, you can use the CLI command bin/console dal:refresh:index.