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

[ADAM-1768] Add InFormatter for unpaired FASTQ. #1769

Merged

Conversation

fnothaft
Copy link
Member

Resolves #1768. Still testing; not ready for merge. Thoughts on how to handle the configuration properties that are shared with InterleavedFASTQInFormatter? I'd rather not duplicate them.

/**
* InFormatter companion that creates an InFormatter that writes FASTQ.
*/
object SingleFASTQInFormatter extends InFormatterCompanion[AlignmentRecord, AlignmentRecordRDD, SingleFASTQInFormatter] {
Copy link
Member

Choose a reason for hiding this comment

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

Single is kinda redundant, how about FASTQInFormatter?

Copy link
Member Author

Choose a reason for hiding this comment

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

SGTM!

@heuermh
Copy link
Member

heuermh commented Oct 19, 2017

Thoughts on how to handle the configuration properties that are shared with InterleavedFASTQInFormatter? I'd rather not duplicate them.

The way you have them now, keyed by fields on FragmentRDD, seems fine to me. Or are you asking a different question?

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2436/
Test PASSed.

@fnothaft
Copy link
Member Author

The way you have them now, keyed by fields on FragmentRDD, seems fine to me. Or are you asking a different question?

No, that's exactly what I'm asking. I guess what I don't like about having them in FragmentRDD is that now you're using them with AlignmentRecordRDD in addition to FragmentRDD. Just seems a bit counterintuitive/awkward for a user.

@fnothaft fnothaft force-pushed the issues/1768-single-fastq-in-formatter branch from 5d751a7 to 1ccbe33 Compare October 19, 2017 19:05
@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2437/
Test PASSed.

@heuermh
Copy link
Member

heuermh commented Oct 23, 2017

No, that's exactly what I'm asking. I guess what I don't like about having them in FragmentRDD is that now you're using them with AlignmentRecordRDD in addition to FragmentRDD. Just seems a bit counterintuitive/awkward for a user.

I see. How about adding those key fields to both AlignmentRecordRDD and FragmentRDD?

Alternatively, we could put them onGenotypeRDD and then refer by specific subclass (AlignmentRecordRDD.WRITE_SUFFIXES) but that is somewhat poor code style.

@heuermh heuermh added this to the 0.23.0 milestone Oct 24, 2017
@heuermh
Copy link
Member

heuermh commented Oct 24, 2017

Created fnothaft#21 to address comment above

@fnothaft
Copy link
Member Author

Alternatively, we could put them on GenotypeRDD and then refer by specific subclass (AlignmentRecordRDD.WRITE_SUFFIXES) but that is somewhat poor code style.

I assume that by GenotypeRDD, you meant RecordGroupGenomicRDD?

@fnothaft
Copy link
Member Author

I'm fine with fnothaft#21 for now, so let's go with that.

@fnothaft
Copy link
Member Author

@heuermh Do you want me to squash down your commit into mine, or leave it separate?

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2454/
Test PASSed.

@heuermh
Copy link
Member

heuermh commented Oct 25, 2017

Squash is ok

@fnothaft
Copy link
Member Author

Squash is ok

Sounds good! I am going to test this later today, and will squash this down once it is OK to merge.

@fnothaft
Copy link
Member Author

I've tested this and it is good to go. Squashing now.

@fnothaft fnothaft force-pushed the issues/1768-single-fastq-in-formatter branch from b62eea9 to 4e3031e Compare October 30, 2017 19:35
@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2456/
Test PASSed.

@heuermh heuermh merged commit 22470c4 into bigdatagenomics:master Oct 31, 2017
@heuermh
Copy link
Member

heuermh commented Oct 31, 2017

Thank you, @fnothaft

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.

3 participants