View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003181||3 - Current Dev List||Bug||public||2019-02-16 18:07||2019-04-03 14:05|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0003181: Logbook requires a database schema migration solution|
There are sevreal bugs (related) which require changes to the Logbook dtabase schema. Adding a new column, removing old columns, adding indexes, or changing database types are common schema migration operations.
We should be able to migrate existing databases to newer database schema definitions. Migration can be a desturctive operation if the schema migration fails, so we should agree on a few goals and limitations and sort-out how we approach the problem.
One of my primary concerns is the operation of the application against old schema. If a schema change is necessary, then the application should disable those features or actions which depend on the new (and unavailable) features when connected to a down-level database. This is possible, but it adds layers of complexity to the application: lots of conditional code based on the detected schema version, alternate displays and options, and so on. This strains development and testing.
One alternative would be to force migration of the databases when the database is first opened. If the migration is declined by the user or fails, then the application refuses to open the database. This avoids the compatibility code bloat issue, but it is awkward because the user will naturally be tentative about porting their database. They won't be able to use the application to perform a backup, since it will refuse to open the data source.
We should evaluate other solutions and decide what's feasible.
The issue is further complicated by the product's diverse support for back-end database providers through ODBC. Different commands and capabilities are required to perform the DDL and DML operations which would be used in schema migration operations, so testing against each supported back-end database server is necessary.
Until agree on a solution, we can't make progress on the related issues.
|Tags||No tags attached.|
|related to||0003142||assigned||WA9PIE||3 - Current Dev List||Logbook does not offer a list of satellites; this causes problems with LOTW upload (and probably awards)|
|related to||0001963||assigned||K7ZCZ||3 - Current Dev List||Can't manually log frequencies above 2.3GHz|
|related to||0002809||resolved||g3ucq||3 - Current Dev List||Some call signs cannot be logged|
|related to||0002267||assigned||1 - Backlog||ADIF Field <qso_date_off> is not being imported|
|related to||0003215||resolved||K7ZCZ||3 - Current Dev List||ALE handles international characters when editing, but not when adding records on SQL Server back-end|
|2019-02-16 18:07||K7ZCZ||New Issue|
|2019-02-16 18:07||K7ZCZ||Relationship added||related to 0003142|
|2019-02-16 18:08||K7ZCZ||Relationship added||related to 0001963|
|2019-02-16 18:12||K7ZCZ||Relationship added||related to 0002809|
|2019-03-06 22:01||K7ZCZ||Relationship added||related to 0002267|
|2019-04-03 14:05||K7ZCZ||Note Added: 0007817|
|2019-04-03 14:05||K7ZCZ||Assigned To||=> K7ZCZ|
|2019-04-03 14:05||K7ZCZ||Status||new => resolved|
|2019-04-03 14:05||K7ZCZ||Resolution||open => fixed|
|2019-04-03 14:05||K7ZCZ||Relationship added||related to 0003215|