[mythtv-users] How to copy 'frontend' portion of mysql database

[Michael T. Dean]

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