[mythtv-users] Failed database update 1327->1328

[Mark Perkins]

> On 22 Jun 2014, at 5:21 pm, "Russell Gower" <mythtv at thegowers.me.uk> wrote:
> 
> 
>> On 21 Jun 2014, at 16:45, Ken Mandelberg <km at mathcs.emory.edu> wrote:
>> 
>> I run the trunk and the most recent update failed trying to update 1327 to 1328.  The first attempt complained about a duplicate entry, the second about a missing column.
>> 
>> How do I recover from this?
> 
> The update consist of two actions, the first one drops the existing index which there is no problem with, the second tries to recreate it as a unique key, this fails if you have any entries in the record table that would be considered a duplicate under the new index.
> 
> To recover I restored the database backup taken at the start of the upgrade, then identified and removed all the records with the duplicate key (chanid, starttime, startdate, title, type) then re-ran the upgrade.
> 
> But once I’d got the upgrade completed the backend was unable to find any of my previous recordings, I’ve not yet had a chance to look into that issue yet as we wanted to watch one of them when we noticed the issue, so I just regressed.
> 
> Regards
>  Russell
> 
> _______________________________________________

I'm a bit puzzled here. I thought that chanid + starttime were unique by definition. So wouldn't chanid + starttime + "anything else" also be unique by definition?

Besides, I'm no DBA (it probably shows...) but seems odd that the intention would be to change the primary key like this (ie by adding more columns, particularly ones that are routinely user editable like title)?