Add Inequality Comparisons to Rules

[gwlester]

Is your feature request related to a problem? Please describe.

It would be helpful to be able to compare if something is GREATER_THAN or GREATER_THAN_OR_EQUAL to a value, e.g. if the current timestamp is greater a particular timestamp.

Describe the solution you'd like

Add the following to the comparison operators:

• GREATER_THAN
• GREATER_THAN_OR_EQUAL
• LESS_THAN
• LESS_THAN_OR_EQUAL
• NOT_EQUAL

Alternatively, provide a documented way to add custom (i.e. user-supplied) conditions to the mapping_by_action set used in _match_by_action.

Describe alternatives you've considered

Additional context

[heitorlessa]

Hey @gwlester - Thanks a lot for another feature request ;)

I think a user supplied would be great here - it can unlock many other use cases customers might want.

cc @risenberg-cyberark @whardier

[whardier]

I agree. I may attempt to patch that in. It would allow for some useful pre optimization as well (re.compile)

[gwlester]

It would also be nice if the init took a logger and only created one if None was passed.

[gwlester]

Maybe this could be combined with feat(feature_flags): add in feature_flags RE_* actions and update tests/docs #692
?

[heitorlessa]

Let’s crate a separate one so it’s easier to know this is a thing for customers reading Changelog/Release notes. I want to accept a Logger instance everywhere in 2.0

…

On Sat, 25 Sep 2021 at 19:16, Gerald Leter ***@***.***> wrote: Maybe this could be combined with feat(feature_flags): add in feature_flags RE_* actions and update tests/docs #692 <https://github.com/awslabs/aws-lambda-powertools-python/pull/692/files>? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBBSD2AQDYEQYIIJH4TUDZC5FANCNFSM5EXUIYGA> .

[gwlester]

Ok, do you want a separate ticket to track "accept a Logger instance everywhere in 2.0"??

Note -- that should not need a major revision roll since if the code looks like the following it is compatiable:

   def __init__ (self, logger=None):
       if logger == none:
           logger = logging.getLogger(__name__)

Is equivalent.

[ran-isenberg]

@heitorlessa @gwlester When I created the feature, I didnt want to add too many actions right at the beginning but to start with sometihng that covers my basic needs. It's great that people are using it and we should add more actions.
The only concern i have is regarding schema validation here for condition value, should we keep it as it is today - just check that it's not empty, or perhaps enforce more validation in case it's greater than (check int/float etc.). what do you think?

[ran-isenberg]

and bring your own logger should definitely be supported.

[heitorlessa]

Only one separate ticket for supporting Logger in the feature flags utility. Feature flags is also beta so I’m not worried in genera as we’ve been waiting for customer feedback to improve it overall

…

On Sun, 26 Sep 2021 at 00:45, Gerald Leter ***@***.***> wrote: Ok, do you want a separate ticket to track "accept a Logger instance everywhere in 2.0"?? *Note* -- that should not need a major revision roll since if the code looks like the following it is compatiable: def __init__ (self, logger=None): if logger == none: logger = logging.getLogger(__name__) Is equivalent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBG7HIPANCRQUDTVFF3UDZGJJANCNFSM5EXUIYGA> .

[gwlester]

@heitorlessa, done see Allow bring your own logger to Feature Flags #702

[gwlester]

@heitorlessa @gwlester When I created the feature, I didnt want to add too many actions right at the beginning but to start with sometihng that covers my basic needs. It's great that people are using it and we should add more actions. The only concern i have is regarding schema validation here for condition value, should we keep it as it is today - just check that it's not empty, or perhaps enforce more validation in case it's greater than (check int/float etc.). what do you think?

I'd not add any additional checking. An exception today causes a failed condition and that is enough.

[gwlester]

I think the conditions need to be named clearer than I suggeted:

• KEY_GREATER_THAN_VALUE
• KEY_GREATER_THAN_OR_EQUAL_VALUE
• KEY_LESS_THAN_VALUE
• KEY_LESS_THAN_OR_EQUAL_VALUE
• KEY_NOT_EQUAL_VALUE

I will attempt to do a Pull Request for the above on 2021.10.01