Question: database migrations about mcrit

[danielplohmann]

Hi!

So far I have been very careful to avoid the need for "real" migrations like that, and in fact, so far MCRIT has been very backwards stable (my test instance was initialized with version 0.9.0 and there were no breaking changes in that time).
Even when splitting results in samples/functions for performance/speed, that wouldn't be an issue as the split version would then be the new default with support for "legacy" full reports.

However, if a user decides to change anything regarding indexing (seeds, shingling composition, minhash length, ...) - sure, that will incur necessary re-indexing of everything.
When there will be .NET support in SMDA, those samples will have their own Minhashing, so that's okay.
Right now, I can only imagine changing the core methodology if something has significantly better performance while maintaining compatibility with MinHash as LSH method.

[danielplohmann]

As demonstrated in the release of v1.3.0, we will aim for providing migrations in the back-end that allow easy upgrades to any changes of future functionality or scheduling reindexing, whenever that may become necessary.