-
Notifications
You must be signed in to change notification settings - Fork 242
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
Improved SRA tests, corrected error message #638
Conversation
@@ -61,7 +61,8 @@ public SRAFileReader(final SRAAccession acc) { | |||
this.acc = acc; | |||
|
|||
if (!acc.isValid()) { | |||
throw new IllegalArgumentException("Invalid SRA accession was passed to SRA reader: " + acc); | |||
throw new IllegalArgumentException("SRAFileReader: cannot resolve SRA accession '" + acc + "'\n" + |
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.
isn't it clear at some point in the code that a connection has been established but that the accession is bad? why not inform the user?
@a-nikitiuk back to you. only one comment really: can you not distinguish between a bad connection and a bad accesssion string? It seems that some part of the code must know, so perhaps you can give an return code to isValid() that will be more than a boolean and work with that. The problem is that if the accession becomes "bad" because of code change we will never find out because we will skip the test. |
Unfortunately, it is not possible in current version of NGS API. We are working on improvement, but that is not an easy and quick fix. |
In that case @a-nikitiuk I think it would be better to test connectivity with a single |
@a-nikitiuk This needs to be rebased, and also did you have time to think about my suggestion of using |
@a-nikitiuk will you have time to rebase and replace We would love to have these changes.... |
Yeah, will do that. Sorry, did not have much time lately |
Rebased and added |
} | ||
|
||
if (accession != null && | ||
accession.matches(SRAAccession.REMOTE_ACCESSION_PATTERN) && !canResolveNetworkAccession) { |
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.
Since you are no longer asking to connect for every accession, wouldn't it be better to remove the first condition, so that if someone puts in a non-matching accession to a new test, it will fail?
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.
If someone puts a non-matching accession, then this code will do nothing. However, it detects remote accessions from its first argument, and if remote accession is detected and canResolveNetworkAccession
is false
then it skips the test.
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.
Oh, OK. can you then simply change the text in the Exception to:
- note the accession that cannot be resolved, and
- change "SRA accession" with "remote SRA accession"?
@a-nikitiuk are you planing to make these changes, or should I do them? |
You can do them if you would like to. Or I will try to find time for that today-tomorrow |
OK. I'll leave it to you then! thanks! On Tue, Jul 26, 2016 at 2:20 PM, a-nikitiuk [email protected]
|
Done |
thanks! 👍 |
* Fixed SRA tests issues, corrected error message * Network related tests now depend on ability to resolve single SRR000123 accession
Description
These changes are intended to resolve most of previously reported SRA-related issues:
Checklist