[mythtv] [mythtv-commits] Ticket #13261: Better solution for schema or protocol mismatch

[Michael T. Dean]

On 04/30/2018 11:17 AM, MythTV wrote:
> #13261: Better solution for schema or protocol mismatch

>   There are compile options -DIGNORE_SCHEMA_VER_MISMATCH
>   -DIGNORE_PROTO_VER_MISMATCH that nullify the database check and upgrade
>   process and the protocol version check process. These seem to be dangerous
>   options, particularly since they have to be compiled into the system to
>   use them.
>
>   There may be cases where you want to ignore schema or protocol mismatch.
>   The attached patch allows the use of override parameters -O
>   !IgnoreSchemaVerMismatch=1 -O !IgnoreProtoVerMismatch=1 at run time. This
>   way you do not have to build the system with those dangerous options, you
>   can ignore the errors for a single run. Also the IgnoreSchemaVerMismatch
>   only works for mythfrontend. Using it on mythbackend may be risky.

The whole reason these were made compile-time options rather than 
settings is so that they wouldn't be put into packaged releases so that 
users wouldn't expect the ability to run mismatched versions since we 
only support running versions where the protocol and schema version 
match.  The idea of making them "hard to get to" was to ensure that they 
were only used with great consideration--and the (user's) knowledge that 
doing so may well break your entire MythTV data set (where packager's 
knowledge of this fact is irrelevant to a user who loses everything due 
to incompatibilty).

I still believe that if they're user-configurable settings (and 
especially if they're relied on by packaged releases) that users will 
come to believe that we support full forward and backward compatibility 
of versions, so we might need to consider a way to achieve that goal if 
this is really a desired solution.

Personally, my opinion is that we should be able to achieve full 
database version independence by creating a dedicated data server and 
never using direct SQL to access/write/retrieve data, but using some 
other protocol to access the desired data (something like the MythTV 
services or MythTV protocol or even something new) and coding the users 
of the data to be resilient to differences in expected data and/or 
handling errors in a user-friendly fashion--the latter of which we've 
never done.  More importantly, if an always-schema-version-correct data 
server is the only component allowed to write data, it can handle data 
differences safely--whether refusing to write data because it's too-far 
different or because it's lacking critical values or choosing to write 
the data and convert "old-format" data and choose appropriate defaults 
for missing data.  Until then, I think encouraging running different 
MythTV components against mismatched schema version/schema-version 
support is likely to only cause problems (which can definitely be 
discouraging for users who lose data on a thousand recordings due to 
corruption caused by some schema change they didn't think would be an 
issue).

And, of course, protocol version independence is simply an issue of 
coding every communications point to have resiliency/error checking 
and/or coding support for every known (or supported) protocol version 
(to achieve backwards compatibility).  In fact, this is actually part of 
the above database-schema-version-independence solution--if we simply 
change all data access to be done through a data server to which we 
communicate through some protocol version and code for data resiliency.

Mike