One possible solution to cigarLen>65535 (DON'T MERGE; for discussion only) #938
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
First of all, this PR is not intended to be merged. It is only meant to show code changes for a solution to CIGARs with >65535 operations. The solution was first proposed here (solution 1). It is not the solution @yfarjoun and I have agreed on, but it probably requires the least code change. The other solution needs to add a few hundred lines of code to htsjdk across multiple files.
You can see how the approach works from the change to BAMRecordCodec.encode(). When cigarLen is too large, we write indexingBin, cigarLen and flags differently. The decoder sets the correct values for these fields once the BAMRecord is read to memory.
./gradlew test
reported "all tests passed" in the end, but this doesn't tell us whether/how my changes work with a new BAM with long cigars.Checklist