Remove timeout behavior of translation engine rule tests

[daxhaw]

This change will cause the translation engine ruleset tests to hang if the rules are not called at all. This "wait_for_rule" function now just waits for global variables to be set inside the rule so they are no longer dependent upon timing. TeamCity itself will flag long-running builds and warn us that they are hanging as part of build alerts.

These changes fixed if_stmt2 as well which I was also seeing failing locally.

There is still a chance that a rule is called when it shouldn't be. Verifying that a rule is not called is tougher than verifying that a rule is called. My only choice here was to move the verification that a rule was called after verifying that all the rules that were supposed to be called were called. I'll watch teamcity to see if this leads to other failures.

In the tag_define_rules test we actually had another race condition where the rule was finishing and setting the flag but then we were immediately checking that another's table value was changed (the rule sums course hours on insert of a registration record). My guess is that the global was set but the rules_engine hadn't committed the rule transaction so those values were not changed in time for the test to verify them. The fix for this was to add another rule that fires when the table's column in question (course.hours) was updated. Waiting on this rule guarantees that the rule that fired on insert had committed.

I kicked off Production_gdev_18_04 and ProductionGaiaRelease_gdev builds off my branch to see if they pass with these changes as well.

[senderista]

So, here's a somewhat higher-level question prompted by the race you mentioned: for transactions that mutate non-transactional global state, shouldn't we provide a way to make that mutation also transactional, i.e. conditional on the transaction committing? I guess this would really just mean exposing triggers directly to the client? Isn't this something that our customers will actually need to do, for side-effects within a transaction that can't be rolled back or shouldn't be visible unless and until the transaction commits? The programming model I imagine here is basically execute_in_transaction(std::function<bool()> txn, std::function<void()> on_commit, std::function<void()> on_abort). This would transparently retry on conflicts and would execute the on_commit() and on_abort() callbacks on respective success or failure (where the latter would presumably be a user-defined failure condition rather than a conflict abort, unless we wanted to allow a user-specified action for retry exhaustion). These callbacks could be executed either on a thread pool or directly on the session thread (the latter of course would be necessary if the callbacks referenced thread-local state).

[senderista]

This seems like the right approach for a test that isn't really verifying perf objectives.

[senderista]

Newline at end of file?

[daxhaw]

Doh. Fixed.

[daxhaw]

@senderista - I think it would be useful to expose transaction events that users could bind to. Just brainstorming here but ideally one could subscribe to the specific commit event for a given rule as the programming model. We currently have no way to identify a specific rule, however. Something like:

OnUpdate(S:Student) : id(my_student_rule)
{
...
}

OnCommit(my_student_rule)
{
...
}

OnAbort(my_student_rule)
{
...
}

[senderista]

@senderista - I think it would be useful to expose transaction events that users could bind to.

So these event handlers would be defined in the ruleset files themselves, i.e. they would be part of the declarative API?