-
Notifications
You must be signed in to change notification settings - Fork 35
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
Implement feature to search jobs with a sp- and doc-integrated filter. #188
Conversation
Codecov Report
@@ Coverage Diff @@
## master #188 +/- ##
==========================================
- Coverage 65.06% 65.03% -0.04%
==========================================
Files 37 37
Lines 5542 5554 +12
==========================================
+ Hits 3606 3612 +6
- Misses 1936 1942 +6
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #188 +/- ##
==========================================
+ Coverage 65.03% 65.10% +0.06%
==========================================
Files 37 37
Lines 5546 5574 +28
==========================================
+ Hits 3607 3629 +22
- Misses 1939 1945 +6
Continue to review full report at Codecov.
|
This patch enables the search for jobs with a statepoint- and document- combined filter. To specify whether a key is a statepoint- or a document-key use prefixes 'sp.' and 'doc.' respectively. No prefix is equivalent to the 'sp.' prefix. This patch is backwards compatible with the exception that the index scheme was slightly modified.
To canonicalize all job-find filters at the JobsCursor stage.
6df43ad
to
99a5847
Compare
I updated your note to point to what I think is the relevant signac-dashboard issue, but please correct it if that's not the one you wanted. |
Thx, I've edited it slightly to say "related to" instead of "resolves", because dashboard might still need a minor update to work with this properly (at least we would need to test that). |
return _with_message(q, file) | ||
|
||
|
||
def parse_simple(tokens): |
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.
I would prefer to keep this "private" by renaming to _parse_simple
and renaming the current _parse_simple
to _parse_simple_single
or so. I recognize that you probably did this to support importing into other modules where it's used, but I don't think we need to bloat the API.
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.
I'm ok with the name change, however, I was actually hoping to expose this function publicly, to make it easier to implement custom user scripts like this:
import click
@click.command()
@click.argument('filter', nargs=-1)
def cli(filter):
jobs = project.find_jobs(parse_simple(filter))
cli()
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.
I support making this a public method / official API - if it's not public then signac-dashboard
has to rely on a private method.
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.
Got it, in that case I support making it part of the API as well. I still like renaming the _parse_simple
method to indicate that it operates on one filter component at a time, but we don't have to change the parse_simple
method.
elif '.' in key and key.split('.', 1)[0] in ('sp', 'doc'): | ||
yield key, value | ||
elif key in ('sp', 'doc'): | ||
yield key, value |
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.
What is the purpose of this branch?
On a related note, should we explicitly disallow sp
and doc
as statepoint/document keys in addition to dots in keys?
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.
For these cases, we need to ensure to not add 'sp' or 'doc' as prefixes, for instance with a filter that is expressed like this: {"sp": {"foo": 0}}
.
Concerning your second point, sp
and doc
are actually valid keys, you would need to "escape" them like this: {"sp.sp.foo": 0}
. However, I agree that we should probably discourage that, possibly even with warnings, and make sure to explicitly test the correctness of the behavior in that case.
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.
I didn't consider that using sp
and doc
as root-level keys in a standard query format was an option, but in hindsight that makes sense. I support discouraging the usage of those as keys to future-proof ourselves against future changes where that might cause problems, though.
@@ -1306,7 +1295,7 @@ def _read_cache(self): | |||
return cache | |||
|
|||
def index(self, formats=None, depth=0, | |||
skip_errors=False, include_job_document=True): | |||
skip_errors=False, include_job_document=True, **kwargs): |
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.
Do we actually need to support arbitrary kwargs here?
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.
No, that is an error. I was trying to introduce backwards compatibility here, and I think we should probably still do that in the long run, but as of right now, the kwargs
are unnecessary.
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.
Thx for your review @vyasr!
return _with_message(q, file) | ||
|
||
|
||
def parse_simple(tokens): |
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.
I'm ok with the name change, however, I was actually hoping to expose this function publicly, to make it easier to implement custom user scripts like this:
import click
@click.command()
@click.argument('filter', nargs=-1)
def cli(filter):
jobs = project.find_jobs(parse_simple(filter))
cli()
elif '.' in key and key.split('.', 1)[0] in ('sp', 'doc'): | ||
yield key, value | ||
elif key in ('sp', 'doc'): | ||
yield key, value |
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.
For these cases, we need to ensure to not add 'sp' or 'doc' as prefixes, for instance with a filter that is expressed like this: {"sp": {"foo": 0}}
.
Concerning your second point, sp
and doc
are actually valid keys, you would need to "escape" them like this: {"sp.sp.foo": 0}
. However, I agree that we should probably discourage that, possibly even with warnings, and make sure to explicitly test the correctness of the behavior in that case.
@@ -1306,7 +1295,7 @@ def _read_cache(self): | |||
return cache | |||
|
|||
def index(self, formats=None, depth=0, | |||
skip_errors=False, include_job_document=True): | |||
skip_errors=False, include_job_document=True, **kwargs): |
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.
No, that is an error. I was trying to introduce backwards compatibility here, and I think we should probably still do that in the long run, but as of right now, the kwargs
are unnecessary.
I'm going to close this until we work on 1.3. |
@vishav1771 please comment on here and let me know if you're OK with switching to work on this for now (regarding my comments from #309). |
@vyasr That's okay. 👍 |
This is moved to #332 . |
Description
This patch enables the search for jobs with a statepoint- and document-
combined filter. To specify whether a key is a statepoint- or a
document-key use prefixes 'sp.' and 'doc.' respectively. No prefix is
equivalent to the 'sp.' prefix.
This patch is backwards compatible with the exception that the index
scheme was slightly modified.
Related to issue glotzerlab/signac-dashboard#25 .
Minimal example
This patch enables queries such as this one:
Equivalently on the command line:
$ signac find foo 0 doc.bar true
All keys without a prefix are automatically interpreted as having the
sp.
prefix.Motivation and Context
It is difficult to impossible to search jobs by filter and document-filter encoded by a simple string. That makes it impossible for example to search properly using signac-dashboard. This patch enables searching with one combined filter, while searching with two filters is still possible
Types of Changes
1The change breaks (or has the potential to break) existing functionality.
Checklist:
If necessary:
Tasks
sp
anddoc
as root-level keys in documents.