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

[Jeremy Palenchar]

> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-
> bounces at mythtv.org] On Behalf Of Michael T. Dean
> Sent: Saturday, June 12, 2010 9:36 AM
> To: Development of mythtv
> Subject: Re: [mythtv] Ticket #8215: MythWeb hostname/setting hostname
> comparison is not case-insensitive
> 
> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

OK,

I have never tried the partial-restore approach so I only jumped in on the
original thread when I ready the line:

After the partial restore, you need to reconfigure /everything/ in
mythtv-setup and mythfrontend settings for every single host in your system
(because all you will have kept is the recordings, recording rules, and
recording history data).

That seems like it could be a painful process and could end up with the user
in a worse situation than when they started if they can't remember how the
system was configured.

What about taking the configuration data and serializing it down to a file
that could then be deserialized and committed back to the new database once
it has been rebuilt?

-Jeremy