sqllogictest

Check-in [ccae19bc34]
Login

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: ccae19bc3444759b9244ef44d72a07315d3d4f40
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
Unified Diff Ignore Whitespace Patch
Changes to about.wiki.
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
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 as the reference database
engine:

<blockquote><pre>
sqllogictest -engine MySQL prototype.test >full.test
</pre></blockquote>



Then verify the results using SQLite:

<blockquote><pre>
sqllogictest -verify -engine SQLite 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 -engine MySQL prototype.test >full-1.test
sqllogictest -engine SQLite 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 -engine MySQL prototype.test >full-1.test
sqllogictest -engine SQLite 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







|
|


|


>
>
|


|














|
|









|
|







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
150
151
152
153
154
155
156
157
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>&lt;type-string&gt; &lt;sort-mode&gt;</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







|







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>&lt;type-string&gt; &lt;sort-mode&gt; &lt;label&gt;</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 &lt;label&gt; 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 "@".