[mythtv-users] Database versioning
Hika van den Hoven
hikavdh at gmail.com
Sun Jan 25 16:05:25 UTC 2026
Hoi Mike,
Sunday, January 25, 2026, 5:48:14 AM, you wrote:
> Greetings!
> Throughout the past couple of decades, I have had this random
> question but have never asked it regarding the versioning of the database versus the client.
> Why are these so intrinsically linked that a newer client cannot talk to an older database?
> I imagine a system something like ZFS feature flags that become
> supported with a new version, but provided your database does not
> have those features the app does not use them. Essentially the
> database becomes a minimum version and the app realizes what
> features that version supports and does not try to use newer features.
> Was the current strict version matching some specific design
> decision reasoning? Could something like feature flags potentially be implemented?
> To me this would make a lot of sense in as much as an upgrade of a
> client would not force the database to upgrade and you could use
> potentially an older client from a distribution that has not been
> updated in a while along with brand new clients provided the
> database stays the same. The upgrade process would then imply that
> adding new features to the database schema is not a requirement but
> a conscious choice made by the user.
> I'm curious on your thoughts.
> Mike
I'm not involved, but my guess is the answer lies in performance and
fault tolerance.
By doing a version check at startup you do not have to perform a lot
of checks at runtime to prevent crashes due to absent or changed
database fields!
Tot mails,
Hika mailto:hikavdh at gmail.com
"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"
De lerende Mens
More information about the mythtv-users
mailing list