Scott Lamb f01f523c2c refine 1->3 upgrade process ... In hindsight, the "post_tx" step in the upgrade process introduced in e7f5733 doesn't make sense. If the procedure fails at this stage, nothing says it still needs to be completed. If the sample file dirs have to be updated after the database, then there should be another database version to mark that it's fully completed, and indeed that's the purpose version 3 serves. So get rid of the Upgrader trait and just go back to a simple run function per version. In the case of the sample file dir metadata, it actually can happen before the database transaction; the stuff written to the database later just needs to be consistent with what it finds if there's an existing metadata file from a half-completed update. For safety, ensure there are no unexpected directory contents before upgrading 1->2, and ensure the metadata matches before upgrading 2->3.		2018-03-01 09:47:56 -08:00
..
config	knob to reduce db commits (SSD write cycles)	2018-02-22 16:35:34 -08:00
upgrade	move db upgrade logic into db crate	2018-02-28 21:21:47 -08:00
check.rs	initial split of database to a separate crate	2018-02-20 23:15:39 -08:00
init.rs	replace homegrown Error with failure crate	2018-02-20 22:46:14 -08:00
mod.rs	refine 1->3 upgrade process	2018-03-01 09:47:56 -08:00
run.rs	knob to reduce db commits (SSD write cycles)	2018-02-22 16:35:34 -08:00
ts.rs	initial split of database to a separate crate	2018-02-20 23:15:39 -08:00