[mythtv] Re: [mythtv-commits] Re: Ticket #76: mythgame makes two Calls to the Database when only one will do the job.

[Korey Fort]

As you said, "there was a very real possibility that more than one row could
exist either through bugs in work in progress or manually added in a test
DB. "  Is that still not now a possibility? What if the DELETE fails for
some reason and the INSERT works? It's like you said, "Better safe than
stupid."

"There is no reason for any bogus old values to exist, no matter what the
cause, when this is reset on an update."  There would be no bogus old
values.
It would update every row where the value is equal to GameDBSchemaVer.

You know it actually does say, "wontfix" on the ticket (right side about a
third of the way through, next to Resolution.) 
I have no problem with the decision to not accept it. I was not looking for
any ego bolstering; I was only looking for some way to help. Now could
everyone quit being some damn sensitive!  :-)

"Let ye without segmentation fault cast the first int!"

Korey Fort
-----Original Message-----
From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
On Behalf Of Bruce Markey
Sent: Friday, July 08, 2005 1:15 PM
To: mythtv-dev at mythtv.org
Subject: [mythtv] Re: [mythtv-commits] Re: Ticket #76: mythgame makes two
Calls to the Database when only one will do the job.

First of all, to everyone, a bug tracking system is not a chat
room or message board. Questions, suggestions, touchy feely crap
flame wars, pissing contests, etc. belong on the mailing lists
and not polluting the bug status DB.

MythTV wrote:
> #76: mythgame makes two Calls to the Database when only one will do the
job.
>
----------------------+-----------------------------------------------------
>        Id:  76        |      Status:  closed                    
> Component:  mythgame  |    Modified:  Fri Jul  8 09:19:40 2005  
>  Severity:  low       |   Milestone:                            
>  Priority:  minor     |     Version:  head                      
>     Owner:  ijr       |    Reporter:  Korey <k.m.fort at gmail.com>
>
----------------------+-----------------------------------------------------
> Comment (by ):
> 
>  It still wouldn't need a unique constraint if instead of deleting the
>  GameDBSchemaVer row everytime it just updated it. But if it won't be
fixed
>  it won't be fixed,oh well, no since in crying over spilled milk (this
>  tickets closed)!

It's not that this won't be 'fixed' as you say, it will not be
broken again.

On a system that encodes or at least decodes tens of gigabytes over
many hours per day, a query that takes less than 1/1000 of a second
once every couple of months when the game schema is updated is not a
performance factor. It's mind boggling how far out of perspective
this is.

I agree 100% with Isaac that this is a waste of time but I wanted
to specify that this was not just pointlessly massaging the code
but would be a regression. When schema versions in the settings
table were first being added there was a very real possibility
that more than one row could exist either through bugs in work
in progress or manually added in a test DB. There is no reason
for any bogus old values to exist, no matter what the cause,
when this is reset on an update.

Yes, I am proud of you for having heard of such a thing as REPLACE
and figuring out how it works and if you're seeking attention for
this show of insight then you are marvelously clever. However, three
adages come to mind; a little knowledge is a dangerous thing, if it
ain't broke don't fix it, and better safe than stupid.

--  bjm