Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Update the about.wiki to show the -odbc argument and to talk about the label parameter to query records. |
---|---|
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
ccae19bc3444759b9244ef44d72a0731 |
User & Date: | drh 2008-12-02 16:44:05.000 |
Context
2008-12-02
| ||
20:57 | Revise the format of the hash string when the result set size exceeds the hash threshold. Use a named file for the SQLite database. Added select4. check-in: c236fecb76 user: drh tags: trunk | |
16:44 | Update the about.wiki to show the -odbc argument and to talk about the label parameter to query records. check-in: ccae19bc34 user: drh tags: trunk | |
16:27 | Update the references scripts in test/ to conform to the lastest prototypes and to the latest version of the sqllogictest program. check-in: 2024d548ed user: drh tags: trunk | |
Changes
Changes to about.wiki.
︙ | ︙ | |||
41 42 43 44 45 46 47 | the sqllogictest program reads a full script and runs the statements and queries contained therein against a database engine under test. The results received back from the database engine are compared against the results in the full script to validate the output of the database engine. For example, to verify that SQLite gets the same answer as MySQL on a particular set of queries, one might execute commands as follows. | | | | > > | | | | | | | 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 | the sqllogictest program reads a full script and runs the statements and queries contained therein against a database engine under test. The results received back from the database engine are compared against the results in the full script to validate the output of the database engine. For example, to verify that SQLite gets the same answer as MySQL on a particular set of queries, one might execute commands as follows. First complete the prototype script using MySQL accessed through ODBC as the reference database engine: <blockquote><pre> sqllogictest -odbc DSN=mysqlslt MySQL prototype.test >full.test </pre></blockquote> In the command above, you would, of course, substitute whatever DSN string is appropriate for your installation. Afterwards, verify the results using the built-in copy of SQLite: <blockquote><pre> sqllogictest -verify full.test </pre></blockquote> The second command will display any discrepencies between the output generated by SQLite and the reference data that was generated by MySQL in the first command. Notice that the default mode of operation for sqllogictest is completion mode. The -verify command-line option is used to activate validation mode. Another approach to validation is to run the competion step separately for each database engine and save the output in separate test scripts. Then compare the two test scripts using a file comparison utility. For example: <blockquote><pre> sqllogictest -odbc DSN=mysqlslt prototype.test >full-1.test sqllogictest prototype.test >full-2.test diff full-1.test full-2.test </pre></blockquote> Note that in completion mode, the sqllogictest program will ignore any result value contained in its input test script. Or, in other words, it is safe to pass a full test script into sqllogictest running in completion mode. So the previous test could have been run this way: <blockquote><pre> sqllogictest -odbc DSN=mysqlslt MySQL prototype.test >full-1.test sqllogictest full-1.test >full-2.test diff full-1.test full-2.test </pre></blockquote> The long-term vision of the sqllogictest project is to amass a huge collection of prototype scripts. Many of the prototype scripts will be very large, being automatically generated by some dynamic language like Tcl or Perl. Prototype scripts will try queries using all kinds |
︙ | ︙ | |||
143 144 145 146 147 148 149 | expected to succeed. But some statements can deliberately fail. For example, an INSERT statement that violates a UNIQUE or CHECK or NOT NULL constraint might fail. A query record begins with a line of the following form: <blockquote> | | | 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 | expected to succeed. But some statements can deliberately fail. For example, an INSERT statement that violates a UNIQUE or CHECK or NOT NULL constraint might fail. A query record begins with a line of the following form: <blockquote> <tt>query</tt> <i><type-string> <sort-mode> <label></i> </blockquote> The SQL for the query is found on second an subsequent lines of the record up to first line of the form "----" or until the end of the record. Lines following the "----" are expected results of the query, one value per line. If the "----" and/or the results are omitted, then the query is expected to return an empty set. The "----" and results |
︙ | ︙ | |||
175 176 177 178 179 180 181 182 183 184 185 186 187 188 | single row of result, since otherwise the order of results is undefined and might vary from one database engine to another. The "rowsort" mode gathers all output from the database engine then sorts it by rows on the client side. Sort comparisons use strcmp() on the rendered ASCII text representation of the values. Hence, "9" sorts after "10", not before. The "valuesort" mode works like rowsort except that it does not honor row groupings. Each individual result value is sorted on its own. In the results section, integer values are rendered as if by printf("%d"). Floating point values are rendered as if by printf("%.3f"). NULL values are rendered as "NULL". Empty strings are rendered as "(empty)". Within non-empty strings, all control characters and unprintable characters are rendered as "@". | > > > > > > > | 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 | single row of result, since otherwise the order of results is undefined and might vary from one database engine to another. The "rowsort" mode gathers all output from the database engine then sorts it by rows on the client side. Sort comparisons use strcmp() on the rendered ASCII text representation of the values. Hence, "9" sorts after "10", not before. The "valuesort" mode works like rowsort except that it does not honor row groupings. Each individual result value is sorted on its own. The <label> argument is also optional. If included, sqllogictest stores a hash of the results of this query under the given label. If the label is reused, then sqllogictest verifies that the results are the same. This can be used to verify that two or more queries in the same test script that are logically equivalent always generate the same output. In the results section, integer values are rendered as if by printf("%d"). Floating point values are rendered as if by printf("%.3f"). NULL values are rendered as "NULL". Empty strings are rendered as "(empty)". Within non-empty strings, all control characters and unprintable characters are rendered as "@". |
︙ | ︙ |