Add Inequality Comparisons to Rules

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

@gwlester

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

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

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

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

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> .

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.

@heitorlessa

@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?

and bring your own logger should definitely be supported.

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> .

@heitorlessa

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

@heitorlessa

@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.

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

I personally don't like how the exception is handled in the case where matching the value of False (which results in True) would match an exception. Not sure if this is intended to allow for exceptions to act this way by design and not disrupt the process.

@heitorlessa

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

Thanks a lot for that - I've just made the necessary changes and merged it.

@heitorlessa

@heitorlessa, will this one make next week's release?

If anyone could help getting the tests and merge conflicts in place by Monday EOD, yep it will ;-)

Tests and conflicts are done.

@heitorlessa

@heitorlessa -- I think this should have the label: status/staged-next-release

Yes! Added earlier but was offline - all good to be released either tomorrow or Wed the latest

…

On Mon, 4 Oct 2021 at 15:14, Gerald Leter ***@***.***> wrote: @heitorlessa <https://github.com/heitorlessa> -- I think this should have the label: *status/staged-next-release* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBDMR2BJ62KETTM3MPDUFGSDNANCNFSM5EXUIYGA> .

This is now available as part of today's 1.21.0 release -- Thank you for the contribution, credits given at the top ;)

https://github.com/awslabs/aws-lambda-powertools-python/releases/tag/v1.21.0

Navigation Menu

Repository navigation

Add Inequality Comparisons to Rules #701

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add Inequality Comparisons to Rules #701

Description

Activity

heitorlessa commented on Sep 25, 2021

whardier commented on Sep 25, 2021

gwlester commented on Sep 25, 2021

gwlester commented on Sep 25, 2021

heitorlessa commented on Sep 25, 2021

gwlester commented on Sep 25, 2021

ran-isenberg commented on Sep 26, 2021

ran-isenberg commented on Sep 26, 2021

heitorlessa commented on Sep 26, 2021

gwlester commented on Sep 26, 2021

gwlester commented on Sep 30, 2021

gwlester commented on Sep 30, 2021

whardier commented on Sep 30, 2021

heitorlessa commented on Oct 1, 2021

gwlester commented on Oct 1, 2021

heitorlessa commented on Oct 1, 2021

gwlester commented on Oct 4, 2021

gwlester commented on Oct 4, 2021

heitorlessa commented on Oct 4, 2021

heitorlessa commented on Oct 5, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions