[mythtv] [mythtv-commits] mythtv branch master updated by stuartm. v0.28-pre-367-gc93076b

Michael T. Dean mtdean at thirdcontact.com
Wed Oct 23 12:00:47 UTC 2013

On 10/23/2013 02:13 AM, Karl Dietz wrote:
> On 23.10.2013 05:06, George Nassas wrote:
>> On 2013-10-22, at 3:41 PM, Git Repo Owner wrote:
>>> - Log -----------------------------------------------------------------
>>> commit c93076b32d6aab4477edefd553958d6ad98d31bf
>>> Author:    Stuart Morgan<smorgan at mythtv.org>  at Tue, 22 Oct 2013 
>>> 18:08:21 +0100
>>> Committer: Stuart Morgan<smorgan at mythtv.org>  at Tue, 22 Oct 2013 
>>> 20:41:26 +0100
>>> URL:       
>>> http://code.mythtv.org/cgit/mythtv/commit/?id=c93076b32d6aab4477edefd553958d6ad98d31bf
>>> Add columns for season and episode to program and recordedprogram 
>>> tables.
>> Hi, just wondering if there are many more schema updates likely to be 
>> committed in the next little while. I’m trying to put together&  test 
>> a patch for saving the recording device’s name in the recorded table 
>> and each of these schema updates gives me heartburn.
>> No complaints or anything, I only ask so I won’t  keep pushing the 
>> boulder up the hill if it’s likely to quickly roll back down.
> just a hint from past changes. Once the target is agreed upon (there
> will be a text stored to indicate the capture card / input used) you
> can push the schema change to avoid having to manually integrate
> parallel schema changes instead of concentrating on the functional
> aspect of your patch.
> So you could add your "displayname-of-cardinput varchar(64)" column in a
> separate patch to avoid reintegration over and over.
> Regards,
> Karl
> PS: http://code.mythtv.org/trac/ticket/7486 had its schema change four
> years ago and only got commited two month ago. But that was an extreme
> case.

Agreed. IMHO, all submitted patches that require schema changes should 
come in 2 parts:  one with the functional changes and a separate schema 
change patch.  And there's no need to keep updating the schema update 
patch, even if the master schema changes before the patch is integrated, 
since it's completely separate and easy enough for the committing 
developer to update.

It also has the benefit that it makes it completely clear to any user 
considering testing the patch that there's a schema update involved, and 
all the danger/planning that entails.


More information about the mythtv-dev mailing list