[mythtv-users] How to copy 'frontend' portion of mysql database
Michael T. Dean
mtdean at thirdcontact.com
Sun Jan 10 16:21:08 UTC 2010
On 01/10/2010 10:40 AM, Ronald Frazier wrote:
>> But if you had instead spent your time working on
>> http://svn.mythtv.org/trac/ticket/6064#comment:2 , perhaps we could finally
>> do it right.
>>
> 1) This is the first time I've seen that ticket. I had no idea it was
> there. Most of the queries I posted were written 2 years ago (when
> there was no such ticket), and took me about 3 minutes to write.
> 2) I can guarantee you that the time I spent writing all these queries
> (even including the more complicated one for playback profiles) was
> WAY less than the time it would take me to download, comprehend the
> 70KB of code in those patches, and then figure out how to improve upon
> what that ticket does.
> 3) EVEN IF working on that ticket would have taken less time, I
> suppose you are one of those rare, fortunate people who has never
> found himself involved in a very quick and simple discussion, which
> evolves, and then evolves a bit more, and then by the time it's done
> it's take more time than if you had done it another way. Well, good
> for you, but I think a lot of people find it happens for them.
> See...just like this discussion. I thought I'd make a quick post
> defending myself, now I've got to make another post defending myself,
> and I suspect by the time it's all said and done, I'll wish I had just
> ignored your post to begin with :)
I'm not trying to attack you, so no need to defend yourself.
I'm simply trying to remind people that when they directly edit the data
in the database, they can /easily/ break their data such that
MythTV--or, more likely, some /parts/ of MythTV--no longer works properly.
And, you may say, "That's what backups are for," but in truth, when you
do break the data, you often don't find out that it's broken for quite
some time--until you happen to use some other functionality that relies
on the same data. If you test every piece of functionality in Myth (or,
at minimum, every piece of functionality you will ever care to use at
any time in the future) immediately after making a change, the
direct-DB-editing-with-backup approach is safe. Otherwise, the only
safe approach is the
study-all-of-the-MythTV-code-that-touches-that-part-of-the-database-to-ensure-you-do-not-break-the-data-or-the-references-to-the-data
approach.
So, I'd love to see a lot fewer suggestions on the lists and IRC to
"edit the data manually."
Copying settings isn't that difficult since frontend settings are
generally unimportant to start with (save changing the Playback Profile
group from CPU+ to Slim) and can be iteratively changed during use as
you notice things are different from your preferences. That said, I'd
guess that for the vast majority of users, the vast majority (>90%, and
probably approaching 99%) of settings and keybindings are defaults. The
Transcoding Profiles may be the one exception, but they take about
75seconds to edit.
In the end, it's "your" data, so feel free to do what you want. (Though
recommending that others edit their data is potentially inciting someone
else to destroy their data, but that's another story.) As long as
someone who breaks their data doesn't report a bug when whatever they've
broken fails to work properly, it's really not a problem.
Unfortunately, most of the time when someone breaks their data, they
assume MythTV is broken, so...
I /do/ edit the data in my database directly--but *only* the database on
my development box (whose database I drop and restore from backup pretty
much every time I do any MythTV development). And, when I do edit the
development data directly, it's usually to try to figure out how someone
else who corrupted their data broke their Myth. I haven't found a need
to directly edit the data in my production database for years--as by now
we've added places to access the data that needs to be changed.
Anyway, just my opinion--heavily swayed by the amount of time I've spent
debugging issues that were caused by invalid data, often due to direct
DB data editing.
Mike
More information about the mythtv-users
mailing list