Object Bricks for Category-specific Attributes

[gutentag2012]

We are newly adopting Pimcore at the moment and are trying to find the best way to represent category-specific attributes on a product.
Based on the Pimcore courses it seems like Object Bricks are the recommended way to go, however it is not possible for us to have 1 Object Brick per category since some categories share the same attributes and Object Bricks need to have unique fields.

For example:
I have a Product Category that requires the attributes "tip shape" and "tip length"
Now another Product Category requires the attributes "tip shape" and "blade dimensions"

Working with object bricks I would have no other way than to split that up into 3 separate bricks "tip shape", "tip length", "blade dimensions" and usually products have way more category-specific attributes than that.
So we ended up creating over 100 object bricks which makes it pretty much impossible to find and assign the correct ones in the object brick field on a product.

Is there any way to improve this workflow or any other recommendation to go about this problem?

[markus-moser]

I would either copy the same attributes to multiple bricks and do some custom logic when reading the data for the output channels or think about using the classification store (https://pimcore.com/docs/platform/Pimcore/Objects/Object_Classes/Data_Types/Classification_Store/).

[gutentag2012]

Thank you for your answer. Unfortunately, Classification Stores are not supported for the GraphQL endpoints which is needed in my case.
As for the custom logic, I am not sure where to start with that since there might be quite a lot of Categories that overlap and creating such a logic for each would add quite a lot of complexity.

I will keep looking, but thank you for your answer. Maybe it would even be better to do custom endpoints for the Classification Stores instead of the GraphQL endpoints.

[filippo-groppi]

We have the same problem. We ended up creating a lot of object bricks. We've tried to use custom layouts on object bricks but with no success.

[filippo-groppi]

I reply to myself due to the fact the community is almost dead. If Pimcore has to grow, also the community needs too.

We've created a lot of object bricks linked to a generic product class. That has ended up in a big problem. Now we can't open product list in search, edit and export view cause objects have too many fields.
Note that I have object bricks with more than 200 fields and I have about 40 object bricks.
So what to do now? Also I can't use classification store due to the fact they doesn't allow structured data in them.

The documentation lacks. Is a huge problem.

Someone told me to split product data in "subclasses". For example "electrical data", "mechanical data" etc. Is a big problem for the product data managers that every day have to fill in data with speed.

I am in almost the same situation of @Wollitoo

[AlephCode]

@filippo-groppi Many of us face the same challenges in managing category-specific attributes in Pimcore. Large-scale use of Object Bricks leads to performance and scalability issues, making it less than ideal.

Pimcore has a great opportunity to improve flexibility and scalability in attribute management. More out-of-the-box solutions could reduce the need for custom work.

Possible improvements:

• Expand Classification Store to support structured data and GraphQL.
• Optimize Object Bricks for better performance with large datasets.
• Introduce a more dynamic attribute assignment system to reduce fragmentation.

Pimcore’s community has potential, but the lack of documentation and discussion makes finding solutions difficult. Addressing these issues would enhance adoption and efficiency.

[Wollitoo]

We assigned the common attributes to a base class and created bricks for each category and distinguished them between product properties, materials, content and texts. In total we have around 40 bricks. We painfully learned later on that having lots of bricks is really horrible because Pimcore takes a lot of time to load the objects. Querying more than like 20 objects at a time with a e.g. listing or via object relation is straight up impossible.

To counter this effect we are not implementing "shadow objects" which are just a very small representation of the big class and use that one in object relation fields.