Allow force option when schema version matches

Since the alert types are determined dynamically from the protocol definition, the status schema may need to be updated even if nothing changed in the scripts, when the dish software adds a new alert type (which just happened, say hello to the "mast_not_near_vertical" alert). This allows the manual override for that case, not just schema version downgrade.
This commit is contained in:
sparky8512 2021-02-15 19:23:37 -08:00
parent a4bf2d1625
commit 18829bd5cb
2 changed files with 14 additions and 4 deletions

View file

@ -12,6 +12,14 @@ at https://github.com/sparky8512/starlink-grpc-tools/issues explaining the use
case and how you would rather see it. This only affects a few fields, since case and how you would rather see it. This only affects a few fields, since
most of the useful data is not in arrays. most of the useful data is not in arrays.
Note that using this script to record the alert_detail group mode will tend to
trip schema-related errors when new alert types are added to the dish
software. The error message will include something like "table status has no
column named alert_foo", where "foo" is the newly added alert type. To work
around this rare occurrence, you can pass the -f option to force a schema
update. Alternatively, instead of using the alert_detail mode, you can use the
alerts bitmask in the status group.
NOTE: The Starlink user terminal does not include time values with its NOTE: The Starlink user terminal does not include time values with its
history or status data, so this script uses current system time to compute history or status data, so this script uses current system time to compute
the timestamps it writes into the database. It is recommended to run this the timestamps it writes into the database. It is recommended to run this
@ -52,8 +60,8 @@ def parse_args():
group.add_argument("-f", group.add_argument("-f",
"--force", "--force",
action="store_true", action="store_true",
help="Override database schema downgrade protection; may result in " help="Force schema conversion, even if it results in downgrade; may "
"discarded data") "result in discarded data")
group.add_argument("-k", group.add_argument("-k",
"--skip-query", "--skip-query",
action="store_true", action="store_true",
@ -139,7 +147,7 @@ def loop_body(opts, gstate):
gstate.sql_conn.commit() gstate.sql_conn.commit()
except sqlite3.OperationalError as e: except sqlite3.OperationalError as e:
# these are not necessarily fatal, but also not much can do about # these are not necessarily fatal, but also not much can do about
logging.error("Unexpected error from database, discarding %s rows: %s", rows_written, e) logging.error("Unexpected error from database, discarding data: %s", e)
rc = 1 rc = 1
else: else:
if opts.verbose: if opts.verbose:
@ -152,7 +160,7 @@ def ensure_schema(opts, conn, context):
cur = conn.cursor() cur = conn.cursor()
cur.execute("PRAGMA user_version") cur.execute("PRAGMA user_version")
version = cur.fetchone() version = cur.fetchone()
if version and version[0] == SCHEMA_VERSION: if version and version[0] == SCHEMA_VERSION and not opts.force:
cur.close() cur.close()
return 0 return 0

View file

@ -113,6 +113,8 @@ their nature, but the field names are pretty self-explanatory.
*alerts*. *alerts*.
: **alert_unexpected_location** : Alert corresponding with bit 3 (bit mask 8) : **alert_unexpected_location** : Alert corresponding with bit 3 (bit mask 8)
in *alerts*. in *alerts*.
: **alert_mast_not_near_vertical** : Alert corresponding with bit 4 (bit mask
16) in *alerts*.
General history data General history data
-------------------- --------------------