[GAIAPLAT-1205] Do not fire a rule if the anchor row is invalid #882
Conversation
daxhaw
requested review from
vDonGlover,
bill-42,
fineg74,
simone-gaia and
JackAtGaia
| { | ||
| } | ||
|
|
||
| rule_checker_t(bool enable_catalog_checks, bool enable_db_checks) |
There was a problem hiding this comment.
Can you comment on what these checks are actually doing?
There was a problem hiding this comment.
I added the following to the class header:
/**
* This helper class is used by the rules engine at both rule
* subscription and invocation time. Currently, the class performs
* the following checks.
*
* Catalog Checks:
* Ensure tables and fields that are referenced in a rule are
* actually present in the catalog at rule subscription time.
*
* Database Checks:
* Ensure that an anchor row is valid before invoking a rule.
*
* Note that the checks can be disabled by unit tests that do not want
* to have a dependency on the database. These tests can intialize
* the rules engine with custom settings. See event_manager_settings.hpp
* and rules_test_helpers.hpp for more information.
*/
| * This helper class is used by the rules engine at both rule | ||
| * subscription and invocation time. Currently, the class performs | ||
| * the following checks. | ||
| * | ||
| * Catalog Checks: | ||
| * Ensure tables and fields that are referenced in a rule are | ||
| * actually present in the catalog at rule subscription time. | ||
| * | ||
| * Database Checks: | ||
| * Ensure that an anchor row is valid before invoking a rule. | ||
| * | ||
| * Note that the checks can be disabled by unit tests that do not want | ||
| * to have a dependency on the database. These tests can intialize | ||
| * the rules engine with custom settings. See event_manager_settings.hpp | ||
| * and rules_test_helpers.hpp for more information. | ||
| */ |
There was a problem hiding this comment.
Trying to determine what user-facing documentation that needs to be provided.
Does affect a rule as it processes and forward chaining?
There was a problem hiding this comment.
There are two important messages:
- Gaia guarantees that a rule is passed a valid anchor row.
- Gaia determines the validity of an anchor row before calling a rule. If the anchor row is invalid, the rule will not be called.
One way for an anchor row to be invalidated is the following sequence events:
- a row is inserted, a transaction is committed and a rule bound to the insert event is enqueued
- that same row is deleted, and a transaction is committed before the rule enqueued in step 1 is invoked
- the rules engine goes to invoke the insert rule enqueued in step 1 but now it won't because that row got deleted. Note that whether the row got deleted in the same transaction as when it was inserted or a different transaction doesn't matter.
|
@simone-gaia , I agree that the rule code should assume the presence of the anchor. The extra 'if' in the generated code is unnecessary. |
|
@simone-gaia, @waynelwarren : I'll look into removing the extra checks now in gaiat. |
|
So what happens when the rules engine checker loses a race with a txn deleting the anchor row, so the check succeeds but the anchor row has been deleted in the rule invocation's snapshot? |
It is possible to delete the row after a rule has been scheduled but before it has been invoked. This results in an invalid row being sent to the rule. We have made the decision to not let this happen. The rules engine now checks that the anchor row is valid before invoking the rule. If an anchor row is not valid, the rule will not be invoked.
Also fixed up tests and enabled a setting to turn this "db checking" off. This is done so that unit tests can test the event manager and rule invocations without the database itself.
Also included a random change to get rid of an unused variable warning in the translation engine. <!sorry>