Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error message in the QB #3682

Merged
merged 3 commits into from
Dec 18, 2019

Conversation

ramirezfranciscof
Copy link
Member

Previous message was not very helpful.

Previous message was not very helpful.
@sphuber sphuber self-requested a review December 17, 2019 15:00
Copy link
Contributor

@sphuber sphuber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ramirezfranciscof . Two small suggested improvements and regarding the commit message, maybe we can make it a bit more informative. How about:

`QueryBuilder`: fix validation bug and improve message for `in` operator

The order of validation checks was incorrect and the type was not
checked at all. In addition the validation error message clarity has
been improved to contain the operator name.

@@ -206,11 +206,11 @@ def get_filter_expr(self, operator, value, attr_key, is_attribute, alias=None, c
''.format(operator, value)
)
elif operator == 'in':
if not value:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if value is not even an interable? This will raise a TypeError, so maybe it is better to first check that a list/tuple is passed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change implemented. In the end I ended up using a try/except statement instead of checking for explicit types (value could also be a set maybe?) because apparently "checking for iterables" is kind of controversial and this is a more "pythonic" approach (sauce). Let me know if you still prefer explicit type checking.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normally that depends on your interface whether it declares a specific type, but in this case I don't think we do so I like your solution 👍

@@ -206,11 +206,11 @@ def get_filter_expr(self, operator, value, attr_key, is_attribute, alias=None, c
''.format(operator, value)
)
elif operator == 'in':
if not value:
raise InputValidationError('Value for operator \'in\' is an empty list')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We indeed prefer single quotes for string literals but not when that requires escaping internal quotes. In this case favor

'Value for operator `in` is an empty list'

or double quotes

'Value for operator "in" is an empty list'

or if you really want single quotes

"Value for operator 'in' is an empty list"

ramirezfranciscof and others added 2 commits December 18, 2019 09:32
Changed again the order of operations to add a first safeguard that
checks if all values provided are effectively iterables. Doing this
before the 'if not' clause also catches any 'None' values that could
otherwise trigger an 'empty list' error message.
@sphuber sphuber merged commit 852a895 into aiidateam:develop Dec 18, 2019
@ramirezfranciscof ramirezfranciscof deleted the improve_qberr branch January 13, 2020 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants