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
DM-35391: Improve query-data-ids command #704
Conversation
Codecov Report
@@ Coverage Diff @@
## main #704 +/- ##
==========================================
- Coverage 84.58% 84.57% -0.01%
==========================================
Files 243 243
Lines 31875 31876 +1
Branches 5982 5977 -5
==========================================
- Hits 26961 26959 -2
- Misses 3744 3745 +1
- Partials 1170 1172 +2
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions on clarifying the logic, and I'd rather it raised an exception than returned a tuple that always had one element be None
.
else: | ||
return None | ||
return None, "\n".join(results.explain_no_results()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this tuple the convention for returning no results explanations elsewhere in the butler? I feel like raising NoResults
(or some other custom exception) with the explanation in the payload would be more pythonic. Looking at the tests, it certainly would simplify this interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a butler convention -- it's trying to bridge the click to script implementation boundary. A specialist exception for this one function seems overkill to me.
|
||
if not graph: | ||
names = [d.name for d in dataset_types] | ||
return None, f"No dimensions in common for specified dataset types ({names})" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I comment below on the other return
statements, I think this makes more sense raising a custom exception or NoResults
.
fc38b16
to
6ac7068
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, those added comments help a lot with understanding the logic.
I'd still prefer a custom exception to a "one is always None" return tuple, but this works.
Also return the reason for failing to get results so that the command line tool can report extra information.
Checklist
doc/changes