added feature to enable or disable rules

[nicolasbisurgi]

To implement on enhancement #1102

[MariusWirtz]

Two thoughts on this.

Explicit enablement and disablement would be nice, especially for potential parallel write interactions.

It would be nice if a disabled rule would be identifiable by criteria other than all lines being commented out.
A kind of "disabled tag" with a current time or something.

[vmitsenko]

Hi both,

The ability to disable/enable rules may be in great demand!

It would also be nice to have an option to disable the Rules and Feeders sections independently, as well as specify whether Skipcheck, Feedstrings and Undefvals should be disabled.

It might also be worth considering adding an additional check when enable = True to ensure that the rule was previously disabled. Otherwise, if you accidentally run a function with enable = True without first disabling it, it may cause the actual comments to be uncommented.

[MariusWirtz]

Thanks for the input on this one @vmitsenko

It would also be nice to have an option to disable the Rules and Feeders sections independently, as well as specify whether Skipcheck, Feedstrings and Undefvals should be disabled.

If we disable only the feeders, we should get all the performance gains without breaking the rule calculations, right?

I like this idea. It is kinda contrary to the direction the PR has evolved though.

Now, we disable the entire rule by replacing it with a commented b64-encoded version of the rule text.
This is more invasive, but it has the advantage that it is undoubtedly identifiable if a rule is currently enabled or disabled.
If we disable it with a plain comment prefix, it is hard to tell whether a rule is enabled or disabled.

Perhaps we can combine both approaches?
We could introduce 4 functions instead of 2 and still use the b64-encoding of rules / feeders:
disable_feeders, disabale_rules, enable_rules, enable_feeders

[nicolasbisurgi]

This is getting interesting!
Now, the problem I see with breaking it down further is that currently the Rule class dismisses all commentaries when defining each component of the rules body.
Should we modify that behavior or just manipulate the rule as plain text?
I would incline for the first option but I'm wondering why comments were left out originally. We could also include a rules_analytics_wtih_comments or something similar.

[vmitsenko]

@MariusWirtz @nicolasbisurgi

Apologies, I didn't notice the second commit, it makes more sense now, thanks for the explanation.

Having 4 functions sounds good to me.

The only thing is that I was unable to complete the write operation when using disable_cube_rule with b64-encoding:

The following test fails with the error "CubeCellWriteStatusRuleApplies":

`
# test disabling
self.tm1.cubes.disable_cube_rule(c)
self.assertEqual(c.has_rules, False)
self.assertEqual(c.rules.text.startswith('# b64 encoded rule='), True)

    # write values
    cells = {}
    cells[('Element 1','Element 1','Element 1')] = 1
    self.tm1.cells.write_values(self.cube_name, cells)

    # test re-enable
    self.tm1.cubes.enable_cube_rule(c)
    self.assertEqual(c.rules.text, uncommented)

`

[nicolasbisurgi]

Hi @vmitsenko
Thanks for doing some additional testing. I added a new commit that will allow to enable/disable rules per subsection:
FEEDSTRINGS, UNDEFVALS, SKIPCHECK and FEEDERS.
Regarding your error:

The following test fails with the error "CubeCellWriteStatusRuleApplies"

It is due to how the construct_body function works on the Cube class:

if self.has_rules:
    body_as_dict['Rules'] = str(self.rules)
return json.dumps(body_as_dict, ensure_ascii=False)

When a rule is completely commented the .has_rules property return False. If we make it look at the body of a rule:

if self.rules.text:
    body_as_dict['Rules'] = str(self.rules)
return json.dumps(body_as_dict, ensure_ascii=False)

then it works fine as shown in the new unit test script.

Let me know your thoughts!

nico

[MariusWirtz]

I added a commit on top. But I had to do it in #1106

I don't think we need different sections, TBH.
I think we only need to enable/disable either the entire rule or all feeder statements.
So, I boiled it down to 4 functions:

    def disable_rules(self, cube_name: str) -> None:
        ...

    def disable_feeders(self, cube_name: str) -> None:
        ...

    def enable_rules(self, cube_name: str) -> None:
        ...

    def enable_feeders(self, cube_name: str) -> None:
        ...

I also separated the string manipulation from the API stuff. That's convenient for the test cases.

Rest should be the same. Let me know what you think!

[MariusWirtz]

closed in favor of #1106