Add a how-to guide in the docs showing how to rebuild of database

[jwreep]

While working on #260, I had updated the units for the hseq_2photon parser (to remove units from A_sum). The database then requires a rebuild in order to correctly parse the updated units, since it has already hard-coded them.

One thought: any update to fiasco that changes parser information like this should then require a rebuild of the database to prevent similar issues. Is there any way to do so?

[wtbarnes]

Sorry, very delinquent in replying to this one. I don't really have any bright ideas here. The first thing that comes to mind is to implement some sort of hashing system but then this would require keeping track of hashes for each dataset or somehow tracking which parts of the code base impact which parts of the database. A brute force method would be to rebuild the database every time the code changes but that seems extreme.

In general, I don't expect the I/O code to change and when it does, those changes are generally being done by experienced users so there's not much chance for gotchas. On top of that, when the tests are run, the database is actually rebuilt from scratch every single time so we should never be caught by this when it comes to running the tests.

[jwreep]

Would it be worth adding a note or example in the docs showing how to rebuild the database manually, then? At least then any user who runs into issues can see an easy solution.

[wtbarnes]

Yes, definitely! I recently refactored the docs so in this new organization, we could have a "how-to" guide for rebuilding the database.

[wtbarnes]

I've changed the title of this issue to make it about adding a how-to guide for rebuilding the database.