[mythtv] Ticket #8215: MythWeb hostname/setting hostname comparison is not case-insensitive
Michael T. Dean
mtdean at thirdcontact.com
Sat Jun 12 16:35:59 UTC 2010
On 06/11/2010 09:55 PM, Nigel Pearson wrote:
> On 12/06/2010, at 4:59 AM, Jeremy Palenchar wrote:
>> I wrote a tool in a former life that would compare the schemas of two
>> different databases and then generate the sql code necessary to make one
>> look like the other.
>> Would it make sense to have such a tool for Myth to repair schemas?
> Perhaps. It would never be an automatic sort of thing,
> but I think something that could compare between two backups,
> or a backup and a live DB, would be good tool for contrib?
I would prefer not having such a tool. My reasons are:
a) There's no way that a schema will become corrupt unless someone does
something they shouldn't be doing (generally editing the schema
directly--though a slightly more understandable cause may be if a user
applies certain (unapplied/unvetted) patches from Trac to their own
local copy without realizing the potential consequences).
b) In-database conversions of data (when types/column
lengths/charset/collation/...) differ can actually corrupt the
data--therefore, even after "fixing," the data is still suspect--not to
mention the problems/confusion that would result when there's a missing
column or table. Throwing away all non-recreatable data and keeping
only data which has no effect on configuration/how MythTV works is the
best way to ensure that all critical data is valid. (Remember that none
of the MythTV application data integrity requirements are expressed in
the database--it's all in application code.) I.e. such a tool could
guarantee a correct schema, but nothing can guarantee valid data.
c) The user loses absolutely nothing using the partial-restore
approach--all non-recreatable data is preserved. Then, the user only
needs to recreate the rest of the data--settings and configuration,
primarily, as well as re-running some tools, such as mythfilldatabase.
d) The issue is very uncommon, so even when it does occur, it's not a
great hardship to use a partial-restore approach to fixing it. And, a
little bit of pain helps enforce the lesson. ;)
e) A ton of users use the partial-restore approach even when they
shouldn't (i.e. "to clean out my database" when they have a valid schema
and data), so it can't be that bad if people choose to do it when its
only benefit is making their lives more difficult. (I can actually do
the partial-restore approach and have my system up and running in 30min.)
f) Maybe more... (The idea just gives me a bad feeling. :)
Thanks for the offer, but I think since there is already a supported
approach that guarantees a valid schema and ensures critical data is
valid after the fix, there's no need for another less-certain tool. If
you do decide to create such a script, it should go to the scripts
section of the wiki ( http://www.mythtv.org/wiki/Category:Scripts ),
which is where most of what used to be in contrib has gone.
Anyway, that's just my opinion.
More information about the mythtv-dev