[
https://issues.apache.org/jira/browse/UNOMI-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Jahanshahi updated UNOMI-549:
-----------------------------------
Description:
Currently when a segment or a scoring is save, there is a validation process
that try to valdiate that the condition of those items are correct.
For doing so it's building the conditionEvaluator and the
conditionESQueryBuilder associated to the item condition and execute them.
This way of doing things is not really efficient because in some case the
Condition could not have the same behavior during the segment save and the real
runtime of the Condition.
This is the case for the PastEventCondition for example.
During the save it doesnt contains yet the autogenerated rules and the
autogenerated property key associated to the counter property store on the
profile, because this is done during the segment creation.
This have a direct impact on the validation, because the validation will then
execute the PastEventCondition in the state where it doesnt have the auto
generated rule.
* it will do large queries and aggregates on existing events and profiles for
nothing, because validation dont care about the result, just to check that it's
not crashing Exceptions
* it's validating a code that will not be used after during the runtime,
because the auto generated rule will be created so the PastEventCondition will
behave differently and use a more optimized code.
So in case of PastEventCondition, the validation is only testing dead code for
nothing.
Proposition:
- implement an optional validation layer at the conditionEvaluator and the
conditionESQueryBuilder level. so then can provide validation function if it's
necessary.
Validation have been introduce here:
https://issues.apache.org/jira/browse/UNOMI-419
was:
Currently when a segment or a scoring is save, there is a validation process
that try to valdiate that the condition of those items are correct.
For doing so it's building the conditionEvaluator and the
conditionESQueryBuilder associated to the item condition and execute them.
This way of doing things is not really efficient because in some case the
Condition could not have the same behavior during the segment save and the real
runtime of the Condition.
This is the case for the PastEventCondition for example.
During the save it doesnt contains yet the autogenerated rules and the
autogenerated property key associated to the counter property store on the
profile, because this is done during the segment creation.
This have a direct impact on the validation, because the validation will then
execute the PastEventCondition in the state where it doesnt have the auto
generated rule.
* it will do large queries and aggregates on existing events and profiles for
nothing, because validation dont care about the result, just to check that it's
not crashing Exceptions
* it's validating a code that will not be used after during the runtime,
because the auto generated rule will be created so the PastEventCondition will
behave differently and use a more optimized code.
So in case of PastEventCondition, the validation is only testing dead code for
nothing.
Proposition:
- implement an optional validation layer at the conditionEvaluator and the
conditionESQueryBuilder level. so then can provide validation function if it's
necessary.
> Strange validation on conditions during segment/scoring save.
> -------------------------------------------------------------
>
> Key: UNOMI-549
> URL: https://issues.apache.org/jira/browse/UNOMI-549
> Project: Apache Unomi
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0, 1.6.0
> Reporter: Kevan Jahanshahi
> Priority: Major
>
> Currently when a segment or a scoring is save, there is a validation process
> that try to valdiate that the condition of those items are correct.
> For doing so it's building the conditionEvaluator and the
> conditionESQueryBuilder associated to the item condition and execute them.
> This way of doing things is not really efficient because in some case the
> Condition could not have the same behavior during the segment save and the
> real runtime of the Condition.
> This is the case for the PastEventCondition for example.
> During the save it doesnt contains yet the autogenerated rules and the
> autogenerated property key associated to the counter property store on the
> profile, because this is done during the segment creation.
> This have a direct impact on the validation, because the validation will then
> execute the PastEventCondition in the state where it doesnt have the auto
> generated rule.
> * it will do large queries and aggregates on existing events and profiles
> for nothing, because validation dont care about the result, just to check
> that it's not crashing Exceptions
> * it's validating a code that will not be used after during the runtime,
> because the auto generated rule will be created so the PastEventCondition
> will behave differently and use a more optimized code.
> So in case of PastEventCondition, the validation is only testing dead code
> for nothing.
> Proposition:
> - implement an optional validation layer at the conditionEvaluator and the
> conditionESQueryBuilder level. so then can provide validation function if
> it's necessary.
> Validation have been introduce here:
> https://issues.apache.org/jira/browse/UNOMI-419
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
