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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
> #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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org