Rule system v2 #3167
Replies: 7 comments
-
What is with the good old topic "HTTP-Cache" and "Rules"? Could that be includeded in a Rule Builder v2 concept as well? |
Beta Was this translation helpful? Give feedback.
-
Reduce rule system, improve tag systemCurrently, our rules access high amounts of product and customer data. The payload of cart line items continues to grow and the indexed fields at the customer are also constantly increasing. The discussion arose to only support However, in order to prevent our customers from ending up in an administration chaos of This could be implemented in several ways: Query approachWe would create a UI for customers and products where the customer can define Script approachWe would read the product during indexing and then call a Twig script. In the Twig script, values can then be queried on the product and the object can be tagged with several tags. A script could look like this: {% set sales = product.sales %}
{% if sales > 1000 %}
{% do product.tags.add('top-seller') %}
{% endif %}
{% if ... || .. %}
{% ... %}
{% endif %}
What does it mean?Individual rules like "Has products from category xy in shopping cart" or "Customer has already placed 10 orders" would be removed and should be realizable over the tag builder. Generic rules like "Line Item has weight > xxx" would stay |
Beta Was this translation helpful? Give feedback.
-
Personally, I would also like it if you add support for dependency injection by separating rule payload and rule matcher, similar to constraints and validators in Symfony validator. However, it could still be helpful and performance should not be an issue as that is up to the developer for a corresponding rule - e.g. I can do slow operations inside the match method already without needing dependency injection - e.g. calling external services or just a plain sleep. |
Beta Was this translation helpful? Give feedback.
-
I understand the point that you would like to use services in the rules, unfortunately they are not designed for that and we don't want to change that in the future. Of course there is already the possibility to program rules slowly, but if we open the window for service injection, this would lead even faster to the use of services and the execution of intensive operations. |
Beta Was this translation helpful? Give feedback.
-
@OliverSkroblin Well as long as one can easy extend the rule payload with custom data from services, it is fine I think which I think the suggestion at the beginning of the proposal would take care of (RuleDataCollection)? If there are corresponding events,. |
Beta Was this translation helpful? Give feedback.
-
I think I would like to split the rule system, so that there are rules responsible for delivering content and rules needed for the shopping cart. This would allow us to evaluate the rules for content independently of the shopping cart. The shopping cart would then only need to be loaded when it is actually needed. My goal would be that listings and detail pages no longer require the shopping cart, so that they can be cleanly cached. The current HTTP Cache rework is already heading in that direction, but it has more of an approach to 'marking' these rules. However, this doesn't prevent the rules from being evaluated. I think I'll rewrite the proposal and focus on splitting the system for content and the shopping cart, as well as how the migration strategy and extensibility look in this regard. |
Beta Was this translation helpful? Give feedback.
-
See: #3406 |
Beta Was this translation helpful? Give feedback.
-
Effort: high
Description:
The current rule system is based on the data of the sales channel context and the user's current shopping cart.
For the implementation of new rules, it is often necessary to adapt the sales channel context or the shopping cart.
If the data is aggregated (product sales, etc.), an indexer is often necessary to make the data available in a performant way.
Therefore, we would modify the rule system so that the data for the validation does not come from the context but from a prepared data collection.
This is assembled before the start of the rule validation and is provided over the scope.
To be discussed:
Benefits
Break strategy
We will add the new data collection in the
RuleScope
class:Beta Was this translation helpful? Give feedback.
All reactions