user/program interface for schema upgrades

[riastradh-probcomp]

Prior to release, automatically upgrading the schema for databases generated by pre-release versions was OK, because everyone is using the most recent version from Git. Once we release, it will be necessary to make upgrading the database schema an explicit action so that when you use Bayeslite 2.0, you don't break the databases of users who are still on Bayeslite 1.3.

[gregory-marton]

Disagree, and recommend wontfix. We should be strongly encouraging upgrading.

Downside of auto-upgrading: This makes collaboration with a given bdb file more difficult, because if one of the group hasn't upgraded, then they get left in the dust, perhaps with a strange error message, or even corruption.
Upside: the only recourse if you wish not to upgrade the bdb is usually not to use the new version of the software. Since the use model (no delete/insert rows) seems to be that we start afresh and re-analyze every time anyway, bdbs should be viewed as "cheap", and backwards compatibility should be a low priority.

[riastradh-probcomp]

wontfix? It's already fixed. The only part of my original description that the system does not reflect is that by default we do corrupt bdb files from older versions, to suppress which behaviour you must pass compatible=True to bayesdb_open.

It seems to me that the use model you describe under 'upside' argues even more in favour of not corrupting bdb files from old versions, because after analysis there is no reason not to treat them as read-only. (Right now we don't have any way to open bdb files as actually read-only -- but that's a separate issue which I think we may be unable to address until #92.)