First, I should announce that I finally fixed the the problem I introduced during last month’s big FATE rework in which the stdout\/stderr blobs were not making it all the way into the MySQL database. I don’t know how that escaped notice during my initial testing. It works again, and after only 3 evenings of analysis and debugging.<\/p>\n
Moving right along, I have also made good on my intention to move FATE’s test database format<\/a> from a pickled Python blob<\/a> to an SQLite database<\/a>. You can download the current database of test specs at:<\/p>\n http:\/\/fate.multimedia.cx\/fate-tests.sqlite.bz2<\/a><\/p>\n Run the file through bunzip2, install SQLite, either through your system’s package manager or from sqlite.org<\/a>, and run:<\/p>\n Be sure to use ‘sqlite3’ vs. ‘sqlite’; the latter invokes v2 of the program.<\/p>\n First things first, study the schema:<\/p>\n And then formulate queries. As an example, get a list of all the tests (short name and command) that are presently disabled:<\/p>\n\r\n $ sqlite3 fate-tests.sqlite\r\n<\/pre>\n
\r\nsqlite> .schema\r\nCREATE TABLE test_spec\r\n (\r\n id INTEGER,\r\n short_name TEXT,\r\n command TEXT,\r\n description TEXT,\r\n expected_status INTEGER,\r\n expected_stdout TEXT,\r\n timeout_seconds INTEGER,\r\n active INTEGER\r\n );\r\n<\/pre>\n
\r\nsqlite>\r\n SELECT short_name, command \r\n FROM test_spec \r\n WHERE active=0;\r\n<\/pre>\n