Should database overwrites be requested by the user? or disabled by user?

[rpetit3]

Really great tool @evolarjun! I'm curious to get your thoughts on handling existing databases.

Currently if a database already exists it is overwritten then downloaded again.

amrfinder -u
Running amrfinder -u
Running /home/rpetit/miniconda3/envs/amr/bin/amrfinder_update -d /home/rpetit/miniconda3/envs/amr/share/amrfinderplus/data
/home/rpetit/miniconda3/envs/amr/share/amrfinderplus/data/2019-09-06.1/ already exists, overwriting what was there
Dowloading AMRFinder database version 2019-09-06.1 into /home/rpetit/miniconda3/envs/amr/share/amrfinderplus/data/2019-09-06.1/
Indexing

I wonder if it would be better to raise an error and require the user to explicitly tell amrfinder (ex --force) to overwrite the existing database.

An alternative, would be allow user to disable the overwrite (ex. --skip_existing).

[evolarjun]

Hi @rpetit3,

Thanks for the compliment! Keep 'em coming :-)

We have it automatically overwriting to simplify things for users (and our support) if/when the database gets moved or corrupted, but we're open to reconsidering and/or adding an option. What is your concern about the way it currently overwrites the database?

[rpetit3]

I think this is a fringe case, but I'm using amrfinder within a conda environment create by Nextflow (https://www.nextflow.io/docs/latest/conda.html).

When the workflow is run, if a conda environment doesn't exist, Nextflow will create it. After creation, amrfinder requires the database to be updated. So, in Nextflow I check to make sure the database exists, and if it doesn't go ahead and update. Occasionally I get instances where multiple jobs try to update at the same time each overwriting one another. I fixed this by updating earlier (a single time) in the workflow.

Probably wasn't the best idea to have multiple jobs trying to update at once, but it got me to wondering: Why update (and overwrite) to the same version of a database? This led to the --force or --skip_existing suggestion.

[evolarjun]

Thanks @rpetit3, That's not something we had thought about since we update so infrequently. I'll talk it over with the rest of the team and see what we can do. I'm glad you've been able to fix the issue short-term and we'll discuss how we can fix it with AMRFinderPlus in the future.

[vbrover]

I suggest having 2 workflows:

• one for the installation of AMRFinder and the database - to be run once;
• and the other one to run AMRFinder on your sequences - can be run in parallel.

[evolarjun]

It only took us a year :-), but we finally implemented your suggestion @rpetit3 in release 3.8.28. The -u/--update option now will not overwrite the database by default and we have a new --force_update parameter to force the overwrite. I know you've already solved your immediate problem, but hopefully this makes it easier for people to add an amrfinder -u so they'll be using the latest database, and race conditions when doing that should be much less likely.

Thanks for your suggestion!

[rpetit3]

Thank you very much! This will work great!