View Issue Details

IDProjectCategoryView StatusLast Update
00031812 - Next Dev List (Holding Area)Bugpublic2019-06-15 11:36
ReporterK7ZCZAssigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Summary0003181: 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.
TagsNo tags attached.
TestingNot Started


related to 0003142 assignedWA9PIE 2 - Next Dev List (Holding Area) Logbook does not offer a list of satellites; this causes problems with LOTW upload (and probably awards) 
related to 0001963 assignedK7ZCZ 3 - Current Dev List Can't manually log frequencies above 2.3GHz 
related to 0002809 resolvedg3ucq 2 - Next Dev List (Holding Area) Some call signs cannot be logged 
related to 0002267 assigned 1 - Backlog ADIF Field <qso_date_off> is not being imported 
related to 0003215 resolvedK7ZCZ 2 - Next Dev List (Holding Area) ALE handles international characters when editing, but not when adding records on SQL Server back-end 



2019-04-03 14:05

administrator   ~0007817

fixed in the 6.7 branch with this checkin:

Issue History

Date Modified Username Field Change
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
2019-06-15 11:36 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)