[mythtv] Ticket #8215: MythWeb hostname/setting hostname comparison is not case-insensitive

[Michael T. Dean]

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.

Mike