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

Incremental import, plus bug fix and doc/code cleanup #28

Merged
merged 20 commits into from
Apr 18, 2019

Conversation

mlathara
Copy link
Contributor

Incremental import support for GenomicsDBImporter.

This dragged on for a while, so I also pulled in a bug fix and some other cleanup. This will currently error out if duplicate callsets/samples are passed in (specifically, duplicates between previously imported samples and current ones).

Caveat emptor: We'll overwrite the existing callset file as part of this, and offer no guarantees as to the integrity of the workspace. That is, if incremental import fails for whatever reason, some of the arrays, callset files, etc might be updated while others may not. We don't offer rollback either.

@codecov
Copy link

codecov bot commented Apr 12, 2019

Codecov Report

Merging #28 into develop will increase coverage by 1.89%.
The diff coverage is 75.75%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop      #28      +/-   ##
===========================================
+ Coverage    74.22%   76.12%   +1.89%     
===========================================
  Files          113      113              
  Lines        16128    16223      +95     
  Branches       257      267      +10     
===========================================
+ Hits         11971    12349     +378     
+ Misses        4016     3714     -302     
- Partials       141      160      +19
Impacted Files Coverage Δ
...c/main/java/org/genomicsdb/GenomicsDBUtilsJni.java 42.85% <ø> (ø) ⬆️
src/main/java/org/genomicsdb/GenomicsDBUtils.java 54.54% <100%> (+17.04%) ⬆️
...nomicsdb/importer/extensions/VidMapExtensions.java 85.96% <100%> (+0.51%) ⬆️
...c/main/java/org/genomicsdb/model/ImportConfig.java 77.67% <100%> (+1.04%) ⬆️
...ain/java/org/genomicsdb/spark/GenomicsDBInput.java 73.91% <46.42%> (+38.83%) ⬆️
...va/org/genomicsdb/importer/GenomicsDBImporter.java 76.74% <61.76%> (-1.52%) ⬇️
.../org/genomicsdb/model/CommandLineImportConfig.java 80.48% <88.88%> (+0.74%) ⬆️
...csdb/importer/extensions/CallSetMapExtensions.java 61.33% <88.88%> (+10.45%) ⬆️
src/main/jni/src/genomicsdb_GenomicsDBUtils.cc 71.25% <96.66%> (+13.25%) ⬆️
src/main/cpp/include/loader/load_operators.h 80.39% <0%> (-7.85%) ⬇️
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f7db32...25bb181. Read the comment docs.

if (value != null) {
throw new GenomicsDBException("Duplicate sample name found: "+sampleName+". Sample "+
"was originally in "+value);
}
Copy link
Member

Choose a reason for hiding this comment

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

It will be useful to get a list of all duplicates before throwing the exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm following what GATK does here for duplicates within an import - they throw exception on the first duplicate. Do you think a (potentially long) list of duplicates would be useful to the users?

Copy link
Member

Choose a reason for hiding this comment

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

We could stop at some predetermined number. But, only if this feature is useful in the first place. Your call.

@nalinigans
Copy link
Member

nalinigans commented Apr 13, 2019

Caveat emptor: We'll overwrite the existing callset file as part of this, and offer no guarantees as to the integrity of the workspace. That is, if incremental import fails for whatever reason, some of the arrays, callset files, etc might be updated while others may not. We don't offer rollback either.

Is it possible to save the original callset file and maybe a list with original fragment names before overwriting, basically the state of the filesystem starting at the workspace, even if we don't offer rollback?

@mlathara
Copy link
Contributor Author

Could save the original callset and fragment names - but if we're doing that, we should probably provide a tool that uses that to recover the original workspace as well...

@nalinigans
Copy link
Member

Agreed, we need a tool to recover the original workspace, but we can start by saving the original callset and fragment names. We should open an issue for writing the tool to recover the original workspace based on what can be gathered from the saved artifacts.

Copy link
Member

@nalinigans nalinigans left a comment

Choose a reason for hiding this comment

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

LGTM

@nalinigans nalinigans merged commit efa1a37 into develop Apr 18, 2019
@nalinigans nalinigans deleted the incremental branch April 18, 2019 17:49
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.

None yet

2 participants