[mythtv] Quality of Service on the HDHomerun

[Michael T. Dean]

On 03/26/2008 11:08 AM, Ronald Frazier wrote:
> Since I need to add a new column to the database, how should that be
> handled in a patch submission? Should I just make note of the
> requirement when I post it, or is there some code I should write to
> handle it? I'm guessing it's more complicated than that, because a
> schema change would bump the DB version number, right?
>   

Generally, what I've found to be a good approach for those of us without
commit access is to create 2 patches.  The first patch provides only the
new functionality (and assumes the DB is properly configured).  The
second patch provides only the dbcheck.cpp update to modify the schema. 
Then, in the ticket, I specify the SQL required for anyone wanting to
test the patch.

The reason this works well is because each change to dbcheck.cpp
requires modifying the DBSchemaVer value.  If you submit the patch as a
single patch that does the dbcheck update, too, then any testers would
end up with a DBSchemaVer that doesn't necessarily correspond to the
true "change history" for the project.

With the 2-patch + SQL in ticket approach, a tester can execute the SQL
commands "manually" (via copy/paste) to alter his/her database and keep
a "standard" DBSchemaVer.  Then, when your patch is committed (and the
DB update) is incorporated into dbcheck.cpp, testers can either undo the
changes to the schema and allow the schema update to proceed or (for
those who are willing to take the risk,) modify the DBSchemaVer value in
their DB to specify that the change has already been made.  (Note,
though, that taking the latter approach is not recommended and really
should not be done unless undoing the DB schema changes and
re-configuring after their re-done is too much work.  And, anyone who
takes this approach is taking on all responsibility for the problems
that could happen if the DB schema is incorrect or if the data is
invalid or ...)

Another benefit of the 2-patch approach--this time for the dev who's
reviewing the patch--is that it's very clear that the change includes a
DB schema version change, so the dev won't forget to update the
currentDatabaseVersion, if (dbver == "xxxx"), and
performActualUpdate(...) lines in the event that dbcheck.cpp has been
modified since you submitted the patch and you haven't yet modified the
whatever-db_update.patch file.

And, the benefit to you is that when other changes to dbcheck.cpp are
committed, you can simply re-roll your db_update patch and the rest
remains unchanged.

I don't know how the devs who actually commit the changes feel about
this approach, but it makes enough sense to me that it's what I've
started to use.  Of course, if the devs say they disagree, then please
ignore me.  :)

HTH,
Mike