Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


mtdean at thirdcontact

Apr 28, 2008, 5:32 PM

Post #1 of 8 (1526 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk

On 04/28/2008 03:00 PM, mythtv [at] cvs wrote:
> Author: danielk
> Date: 2008-04-28 19:00:13 +0000 (Mon, 28 Apr 2008)
> New Revision: 17160
> Changeset: http://cvs.mythtv.org/trac/changeset/17160
>
> Modified:
>
> trunk/mythtv/libs/libmyth/dbutil.cpp
> trunk/mythtv/libs/libmyth/dbutil.h
> trunk/mythtv/libs/libmythtv/datadirect.cpp
> trunk/mythtv/libs/libmythtv/dbcheck.cpp
>
> Log:
>
> Refs #5267. Fixes two chicken and egg problems with DB initialization
...
> The second is not to do the database backup on an empty database, since it will fail to find settings and housekeeping tables.
>

Daniel,

I had a couple of questions about the changes in here. The first one
was regarding your change to DBUtil::GetTables() to remove the check for
whether SHOW FULL TABLES is supported. Are we going to also modify the
minimum MySQL version to 5.0.2 (or, a more appropriate later
version--like the first stable release of MySQL 5; I think Cardoe told
me that was 5.0.15)? I'll do a patch, but I was just wondering if it
would be desired (and what minimum MySQL version seems most appropriate).

Also, your change to not do the backup on an "empty" database (where
dbver != "0") sounds good as long as dbVer doesn't get set to 0 if the
settings table is missing or the DBSchemaVer setting, itself, happens to
be gone from the DB (for the same reason Chris Pinkham reverted his
change at http://svn.mythtv.org/trac/changeset/15933 , i.e.
http://www.gossamer-threads.com/lists/mythtv/dev/315935#315935 ).

And, finally, this adds a check for dbver != "0" before calling
PromptForSchemaUpgrade(), but PromptForSchemaUpgrade() is also doing a
check at libs/libmyth/mythcontext.cpp +3529 (
http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/mythcontext.cpp#L3529
). Since the "old" check--an isEmpty() check--is failing and (I'm
assuming) yours is working, it seems that someone (I don't see where) is
setting dbver to 0 before the call to PromptForSchemaUpgrade() (perhaps
this changed since Nigel(?) first wrote it). Does it make sense to
remove the new check and fix the one in PromptForSchemaUpgrade()?

Thanks,
Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


nigel at ind

Apr 28, 2008, 6:46 PM

Post #2 of 8 (1440 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

> And, finally, this adds a check for dbver != "0" before calling
> PromptForSchemaUpgrade(), but PromptForSchemaUpgrade() is also doing a
> check at libs/libmyth/mythcontext.cpp +3529 (
> http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/
> mythcontext.cpp#L3529
> ). Since the "old" check--an isEmpty() check--is failing and (I'm
> assuming) yours is working, it seems that someone (I don't see
> where) is
> setting dbver to 0 before the call to PromptForSchemaUpgrade()
> (perhaps
> this changed since Nigel(?) first wrote it).


I'm not getting a 0. Just created a new empty DB,
and the schema version is empty:


% MythBackend.app/Contents/MacOS/MythBackend --version
Please include all output in bug reports.
MythTV Version : 17091:17131M
MythTV Branch : trunk
Library API : 0.22.20080422-1
Network Protocol : 40
QT Version : 4.3.4
...

% MythBackend.app/Contents/MacOS/MythBackend
2008-04-29 11:41:30.028 Using runtime prefix = /Volumes/MythBuild/
MythBackend.app/Contents/Resources, libdir = /Volumes/MythBuild/.osx-
packager/build/lib
2008-04-29 11:41:30.029 Using localhost value of
macaque.ind.tansu.com.au
2008-04-29 11:41:30.031 New DB connection, total: 1
2008-04-29 11:41:30.034 Connected to database 'mythtest' at host:
149.135.128.77
2008-04-29 11:41:30.034 Closing DB connection named 'DBManager0'
2008-04-29 11:41:30.036 Connected to database 'mythtest' at host:
149.135.128.77
2008-04-29 11:41:30.041 New DB connection, total: 2
2008-04-29 11:41:30.042 Connected to database 'mythtest' at host:
149.135.128.77
2008-04-29 11:41:30.045 Current Schema Version:
2008-04-29 11:41:30.046 DataDirectProcessor::FixProgramIDs() -- begin
...
2008-04-29 11:41:30.100 No current database version. Auto upgrading
2008-04-29 11:41:30.101 Newest Schema Version : 1219
2008-04-29 11:41:30.104 Inserting MythTV initial database information.
2008-04-29 11:41:30.104 Upgrading to schema version 1112
2008-04-29 11:41:30.231 New DB connection, total: 4
2008-04-29 11:41:30.233 Connected to database 'mythtest' at host:
149.135.128.77
2008-04-29 11:41:30.236 Upgrading to schema version 1113
...



> Does it make sense to
> remove the new check and fix the one in PromptForSchemaUpgrade()?

Some.

Even better would be to fix dbutil::BackupDB()
to not attempt a backup if there are no tables?

--
Nigel Pearson, nigel [at] ind| "They did the
Telstra Net. Eng., Sydney, Australia | white man power dance,
Office: 9202 3900 Fax: 9261 3912 | and ... Shazam"
Mobile: 0408 664435 Home: 9792 6998 | Lois Lane - Smallville

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


danielk at cuymedia

Apr 29, 2008, 6:48 AM

Post #3 of 8 (1431 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On Mon, 2008-04-28 at 20:32 -0400, Michael T. Dean wrote:
> On 04/28/2008 03:00 PM, mythtv [at] cvs wrote:
> > Refs #5267. Fixes two chicken and egg problems with DB initialization
> > The second is not to do the database backup on an empty database, since it will fail to find settings and housekeeping tables.
> >
>
> Daniel,
>
> I had a couple of questions about the changes in here. The first one
> was regarding your change to DBUtil::GetTables() to remove the check for
> whether SHOW FULL TABLES is supported. Are we going to also modify the
> minimum MySQL version to 5.0.2 (or, a more appropriate later
> version--like the first stable release of MySQL 5; I think Cardoe told
> me that was 5.0.15)? I'll do a patch, but I was just wondering if it
> would be desired (and what minimum MySQL version seems most appropriate).

Hmm, I though we were already requiring 5.0.2, if not I'll revert that
part of the fix. I was just trying to avoid this needing to be an
instance method rather that a static function.

> Also, your change to not do the backup on an "empty" database (where
> dbver != "0") sounds good as long as dbVer doesn't get set to 0 if the
> settings table is missing or the DBSchemaVer setting, itself, happens to
> be gone from the DB (for the same reason Chris Pinkham reverted his
> change at http://svn.mythtv.org/trac/changeset/15933 , i.e.
> http://www.gossamer-threads.com/lists/mythtv/dev/315935#315935 ).

I'll look into this.

> And, finally, this adds a check for dbver != "0" before calling
> PromptForSchemaUpgrade(), but PromptForSchemaUpgrade() is also doing a
> check at libs/libmyth/mythcontext.cpp +3529 (
> http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/mythcontext.cpp#L3529
> ). Since the "old" check--an isEmpty() check--is failing and (I'm
> assuming) yours is working, it seems that someone (I don't see where) is
> setting dbver to 0 before the call to PromptForSchemaUpgrade() (perhaps
> this changed since Nigel(?) first wrote it). Does it make sense to
> remove the new check and fix the one in PromptForSchemaUpgrade()?

It's probably best to check both. We could also modify the "empty
database check" to check for the absence of tables. This is what I
did in the datadirect portion of the patch.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Apr 29, 2008, 6:59 AM

Post #4 of 8 (1431 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On Tuesday 29 April 2008 14:48:18 Daniel Kristjansson wrote:
> > I had a couple of questions about the changes in here. The first one
> > was regarding your change to DBUtil::GetTables() to remove the check for
> > whether SHOW FULL TABLES is supported. Are we going to also modify the
> > minimum MySQL version to 5.0.2 (or, a more appropriate later
> > version--like the first stable release of MySQL 5; I think Cardoe told
> > me that was 5.0.15)? I'll do a patch, but I was just wondering if it
> > would be desired (and what minimum MySQL version seems most appropriate).
>
> Hmm, I though we were already requiring 5.0.2, if not I'll revert that
> part of the fix. I was just trying to avoid this needing to be an
> instance method rather that a static function.

We have been requiring MySQL 5.x since December last year, although the minor
version was never settled I doubt any distros were shipping versions prior to
5.0.15 in their stable repositories.

David was the one who made the official announcement on the 8th December, it
was formally agreed between the devs a couple of days before that.

http://www.gossamer-threads.com/lists/mythtv/dev/304388
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Apr 29, 2008, 8:55 AM

Post #5 of 8 (1440 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On 04/29/2008 09:59 AM, Stuart Morgan wrote:
> On Tuesday 29 April 2008 14:48:18 Daniel Kristjansson wrote:
>
>>> I had a couple of questions about the changes in here. The first one
>>> was regarding your change to DBUtil::GetTables() to remove the check for
>>> whether SHOW FULL TABLES is supported. Are we going to also modify the
>>> minimum MySQL version to 5.0.2 (or, a more appropriate later
>>> version--like the first stable release of MySQL 5; I think Cardoe told
>>> me that was 5.0.15)? I'll do a patch, but I was just wondering if it
>>> would be desired (and what minimum MySQL version seems most appropriate).
>>>
>> Hmm, I though we were already requiring 5.0.2, if not I'll revert that
>> part of the fix. I was just trying to avoid this needing to be an
>> instance method rather that a static function.
>>
> We have been requiring MySQL 5.x since December last year, although the minor
> version was never settled I doubt any distros were shipping versions prior to
> 5.0.15 in their stable repositories.
>
> David was the one who made the official announcement on the 8th December, it
> was formally agreed between the devs a couple of days before that.
>
> http://www.gossamer-threads.com/lists/mythtv/dev/304388

And it requires very little in terms of changes to specify a
major/minor/point version (it's either an extremely easy change or just
requires rearranging things a little--just need to do a quick test). We
already have some pretty robust code in place to parse the MySQL server
version as well as a "way out" for those whose packagers changed it to
something unparsable/not useful (which is more likely to occur when
requiring recognizable major/minor/point versions).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Apr 29, 2008, 9:01 AM

Post #6 of 8 (1424 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On 04/29/2008 09:48 AM, Daniel Kristjansson wrote:
> On Mon, 2008-04-28 at 20:32 -0400, Michael T. Dean wrote:
>
>> Also, your change to not do the backup on an "empty" database (where
>> dbver != "0") sounds good as long as dbVer doesn't get set to 0 if the
>> settings table is missing or the DBSchemaVer setting, itself, happens to
>> be gone from the DB (for the same reason Chris Pinkham reverted his
>> change at http://svn.mythtv.org/trac/changeset/15933 , i.e.
>> http://www.gossamer-threads.com/lists/mythtv/dev/315935#315935 ).
>>
>
> I'll look into this.
>

Actually, I think Nigel's idea of having DBUtil::BackupDB() check for no
tables is a good one. It's a quick and easy change, so I can make a
patch for you (so don't waste your time on it :). When I work on it,
I'll test out a couple of corrupted DB scenarios, and we can decide
whether to remove the check before the call to BackupDB(). It will be a
little bit (a week?) before I can switch over my dev system to post-Qt4
trunk, but as soon as I can, I'll do the patch.


>> And, finally, this adds a check for dbver != "0" before calling
>> PromptForSchemaUpgrade(), but PromptForSchemaUpgrade() is also doing a
>> check at libs/libmyth/mythcontext.cpp +3529 (
>> http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/mythcontext.cpp#L3529
>> ). Since the "old" check--an isEmpty() check--is failing and (I'm
>> assuming) yours is working, it seems that someone (I don't see where) is
>> setting dbver to 0 before the call to PromptForSchemaUpgrade() (perhaps
>> this changed since Nigel(?) first wrote it). Does it make sense to
>> remove the new check and fix the one in PromptForSchemaUpgrade()?
>>
> It's probably best to check both. We could also modify the "empty
> database check" to check for the absence of tables. This is what I
> did in the datadirect portion of the patch.

Nigel may have a plan for this now. He added in an = "0" check to
PromptForSchemaUpgrade() and I think he planned to make some changes
when he comes up with a plan for backups on mingw. So, again, it may

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

May 3, 2008, 12:40 PM

Post #7 of 8 (1363 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On 04/29/2008 09:48 AM, Daniel Kristjansson wrote:
> On Mon, 2008-04-28 at 20:32 -0400, Michael T. Dean wrote:
>
>> On 04/28/2008 03:00 PM, mythtv [at] cvs wrote:
>>
>>> Refs #5267. Fixes two chicken and egg problems with DB initialization
>>> The second is not to do the database backup on an empty database, since it will fail to find settings and housekeeping tables.
>> Also, your change to not do the backup on an "empty" database (where
>> dbver != "0") sounds good as long as dbVer doesn't get set to 0 if the
>> settings table is missing or the DBSchemaVer setting, itself, happens to
>> be gone from the DB (for the same reason Chris Pinkham reverted his
>> change at http://svn.mythtv.org/trac/changeset/15933 , i.e.
>> http://www.gossamer-threads.com/lists/mythtv/dev/315935#315935 ).
> I'll look into this.
>
>> And, finally, this adds a check for dbver != "0" before calling
>> PromptForSchemaUpgrade(), but PromptForSchemaUpgrade() is also doing a
>> check at libs/libmyth/mythcontext.cpp +3529 (
>> http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/mythcontext.cpp#L3529
>> ). Since the "old" check--an isEmpty() check--is failing and (I'm
>> assuming) yours is working, it seems that someone (I don't see where) is
>> setting dbver to 0 before the call to PromptForSchemaUpgrade() (perhaps
>> this changed since Nigel(?) first wrote it). Does it make sense to
>> remove the new check and fix the one in PromptForSchemaUpgrade()?
> It's probably best to check both. We could also modify the "empty
> database check" to check for the absence of tables. This is what I
> did in the datadirect portion of the patch.

So, I did some experimentation and figured out what's going on.
Although the default value for MythContext::GetSetting() is "", the
default value for MythContext::GetNumSetting() is 0. And, when you
factor in the settings cache, it turns out that whatever function is
called first wins--so, if gContext.GetNumSetting("DBSchemaVer") is
called first, all calls to gContext.GetSetting("DBSchemaVer") will return 0.

Therefore, since the addition of CompareTVDatabaseSchemaVersion() in
[15902], the schema version checks for "" have all been broken. (Yeah,
that means I broke it. :( ).

So, how best to clean up the mess? Change
CompareTVDatabaseSchemaVersion() to use GetSetting() and toInt() (so
we'll go back to defaulting to "")? Change all the 'if (dbver = "")'
checks to 'if (dbver.isEmpty() || dbver == "0")'? Or, modify the
settings cache to identify "missing"/not-stored settings (i.e. with
QString::NULL and a check for it in GetSetting(), perhaps) so it doesn't
save a specific call's requested default? Thoughts?

Also, this means that any corrupted DB that's missing a DBSchemaVer
setting (or the settings table itself) will no longer be backed up with
the change to check for dbVer == "0" before doing the backup. The
similar check before calling MythContext::PromptForSchemaUpgrade()
prevents asking for permission to upgrade for both empty databases /and/
for corrupt ones without a DBSchemaVer. Since
MythContext::PromptForSchemaUpgrade() is now doing an isEmpty()/=="0"
check), the prompt wouldn't be displayed even without the new check.

So, if I were to modify DBUtil::BackupDB() to check for an empty
database (i.e. the size of the QStringList returned by
DBUtil::GetTables() is 0), can I also remove the new checks for
undefined DBSchemaVer that prevent the backup? And, since the new check
that prevents the prompt is redundant, can I remove it so that the user
will get the VB_GENERAL message, ""No current database version. Auto
upgrading"?

Note, also, that as it stands now, a missing DBSchemaVer in an database
with tables actually allows Myth to run with the wrong schema version
(i.e. the upgrade won't work, but the wrong checks are performed, so it
doesn't error out).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

May 3, 2008, 4:27 PM

Post #8 of 8 (1366 views)
Permalink
Re: [mythtv-commits] mythtv commit: r17160 - in trunk/mythtv/libs by danielk [In reply to]

On 05/03/2008 03:40 PM, Michael T. Dean wrote:
> So, I did some experimentation and figured out what's going on.
> Although the default value for MythContext::GetSetting() is "", the
> default value for MythContext::GetNumSetting() is 0. And, when you
> factor in the settings cache, it turns out that whatever function is
> called first wins--so, if gContext.GetNumSetting("DBSchemaVer") is
> called first, all calls to gContext.GetSetting("DBSchemaVer") will return 0.
>
> Therefore, since the addition of CompareTVDatabaseSchemaVersion() in
> [15902], the schema version checks for "" have all been broken. (Yeah,
> that means I broke it. :( ).

OK, I did up some patches to clean up the mess I made. They're on #5286.

For the committer, the patches should be straightforward with one
exception--only ONE of
mythtv-5286-check_for_empty_or_zero_to_call_InitializeDatabase.patch or
mythtv-5286-use_IsNewDatabase_everywhere.patch should be applied. They
should apply in any order (as I didn't see any overlaps)--but I didn't
test all the combinations. :) (However, compiling
mythtv-5286-use_IsNewDatabase_everywhere.patch depends on
mythtv-5286-no_backup_for_new_database.patch .)

I recommend all of the patches be committed--that is all except one of
mythtv-5286-check_for_empty_or_zero_to_call_InitializeDatabase.patch or
mythtv-5286-use_IsNewDatabase_everywhere.patch . I prefer
mythtv-5286-use_IsNewDatabase_everywhere.patch , but I'll leave the
decision up to you (and, again, I'm happy to modify
DBUtil::IsNewDatabase() if you want).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.