|
1
|
<h1>TH1 "query" API</h1> |
|
2
|
|
|
3
|
The "query" API provides limited access to the fossil database. |
|
4
|
It restricts usage to queries which return result columns (i.e. |
|
5
|
<tt>SELECT</tt> and friends). |
|
6
|
Example usage: |
|
7
|
|
|
8
|
<nowiki><pre> |
|
9
|
<th1> |
|
10
|
catch { |
|
11
|
set stmt [query prepare "SELECT login, cap FROM user"] |
|
12
|
puts "stmt ID=$stmt\n" |
|
13
|
for {} {[query $stmt step]} {} { |
|
14
|
puts [query $stmt col string 0] " " [query $stmt col string 1] \n |
|
15
|
} |
|
16
|
query $stmt finalize |
|
17
|
return 0 |
|
18
|
} rc |
|
19
|
if {0 != $rc} { |
|
20
|
puts "ERROR: $rc\n" |
|
21
|
} |
|
22
|
<th1> |
|
23
|
</pre></nowiki> |
|
24
|
|
|
25
|
The various subcommands are summarized in the following subsections, and here |
|
26
|
are some notes regarding calling conventions: |
|
27
|
|
|
28
|
The (bind, col, step, finalize) functions accept their statement ID argument |
|
29
|
either right after the "query" command or right after the final subcommand. |
|
30
|
The following examples demonstrate this: |
|
31
|
|
|
32
|
<nowiki><pre> |
|
33
|
query $stmt step |
|
34
|
query step $stmt |
|
35
|
|
|
36
|
query $stmt finalize |
|
37
|
query finalize $stmt |
|
38
|
|
|
39
|
query col string $stmt 1 |
|
40
|
query $stmt col string 1 |
|
41
|
|
|
42
|
query bind string $stmt 1 "foo" |
|
43
|
query $stmt bind string 1 "foo" |
|
44
|
</pre></nowiki> |
|
45
|
|
|
46
|
The "prefered" form is: |
|
47
|
|
|
48
|
<nowiki><pre> |
|
49
|
query StmtId command ... |
|
50
|
</pre></nowiki> |
|
51
|
|
|
52
|
(Why, then, are both forms accepted? Because the "preferred" form only |
|
53
|
evolved only after using the first form in script code.) |
|
54
|
|
|
55
|
|
|
56
|
<h2>prepare</h2> |
|
57
|
|
|
58
|
This subcommand prepares a query for execution. It returns a statement handle |
|
59
|
ID which must be passed to any other functions using the API. |
|
60
|
|
|
61
|
All prepared statements must be <tt>finalize</tt>d when they have outlived |
|
62
|
their usefulness. |
|
63
|
|
|
64
|
<nowiki><pre> |
|
65
|
set stmt [query prepare {SELECT ...}] |
|
66
|
... |
|
67
|
query $stmt finalize |
|
68
|
</pre></nowiki> |
|
69
|
|
|
70
|
|
|
71
|
<h2>finalize</h2> |
|
72
|
|
|
73
|
Releases all resources associated with the statement. Note that future |
|
74
|
calls to <tt>prepare</tt> might re-use the same statement statement |
|
75
|
ID. |
|
76
|
|
|
77
|
<nowiki><pre> |
|
78
|
set stmt [query prepare "SELECT ..."] |
|
79
|
... |
|
80
|
query $stmt finalize |
|
81
|
</pre></nowiki> |
|
82
|
|
|
83
|
|
|
84
|
<h2>step</h2> |
|
85
|
|
|
86
|
This subcommand steps the result set by one row. It returns 0 |
|
87
|
at the end of the set, a positive value if a new row is available, |
|
88
|
and throws for any other condition. |
|
89
|
|
|
90
|
<nowiki><pre> |
|
91
|
for {} {[query $stmt step]} {} { |
|
92
|
puts [query $stmt col string 0] "\n" |
|
93
|
} |
|
94
|
</pre></nowiki> |
|
95
|
|
|
96
|
|
|
97
|
<h2>reset</h2> |
|
98
|
|
|
99
|
Resets a query so that it can be executed again. This is only needed when |
|
100
|
binding parameters in a loop - call it at the end of each loop iteration. |
|
101
|
|
|
102
|
<nowiki><pre> |
|
103
|
query $stmt reset |
|
104
|
query reset $stmt |
|
105
|
</pre></nowiki> |
|
106
|
|
|
107
|
|
|
108
|
<h2>bind xxx</h2> |
|
109
|
|
|
110
|
The <tt>bind xxx</tt> family of subcommands attach values to queries |
|
111
|
before stepping through them. The subcommands include: |
|
112
|
|
|
113
|
* <tt>bind StmtId int Index Value</tt> |
|
114
|
* <tt>bind StmtId double Index Value</tt> |
|
115
|
* <tt>bind StmtId null Index</tt> |
|
116
|
* <tt>bind StmtId string Index Value</tt> |
|
117
|
|
|
118
|
Note that all of those optionally accept the statement handle directly after |
|
119
|
the "query" command (before the "col" subcommand). e.g. |
|
120
|
<tt>query bind null $stmt 1</tt> and |
|
121
|
<tt>query $stmt bind null 1</tt> are equivalent. They also accept the column index |
|
122
|
either before or after the type name, e.g. |
|
123
|
<tt>query $stmt bind 1 string ...</tt> and <tt>query $stmt bind string 1 ...</tt> are equivalent. |
|
124
|
|
|
125
|
|
|
126
|
Achtung: the bind API uses 1-based indexes, just like SQL does. |
|
127
|
|
|
128
|
<nowiki><pre> |
|
129
|
set stmt [query prepare "SELECT ... WHERE user=?"] |
|
130
|
query $stmt bind int 1 drh |
|
131
|
if {[query $stmt step]} { |
|
132
|
puts [query $stmt col string 0] "\n" |
|
133
|
} |
|
134
|
query $stmt finalize |
|
135
|
</pre></nowiki> |
|
136
|
|
|
137
|
|
|
138
|
<h2>col xxx</h2> |
|
139
|
|
|
140
|
The <tt>col xxx</tt> familys of subcommands are for fetching values and metadata from result rows. |
|
141
|
|
|
142
|
* <tt>col StmtId count</tt> Returns the number of result columns in the statement. |
|
143
|
* <tt>col StmtId isnull Index</tt> Returns non-0 if the given column contains an SQL NULL value. |
|
144
|
* <tt>col StmtId (double|int|string) Index</tt> Fetches a column's value as either a number or string. |
|
145
|
* <tt>col StmtId time Index Format Modifiers</tt> Formats a time value. See below. |
|
146
|
* <tt>col StmtId type Index</tt> Returns the given column's type as a value from the <tt>SQLITE_TYPENAME</tt> family of constants. |
|
147
|
|
|
148
|
Note that all of those optionally accept the statement handle directly after |
|
149
|
the "query" command (before the "col" subcommand). e.g. |
|
150
|
<tt>query $stmt col count</tt> and |
|
151
|
<tt>query col count $stmt</tt> are equivalent. They also accept the column index |
|
152
|
either before or after the type name, e.g. |
|
153
|
<tt>query $stmt col 1 string</tt> and <tt>query $stmt col string 1</tt> are equivalent. |
|
154
|
|
|
155
|
Achtung: the col API uses 0-based indexes, just like SQL does. |
|
156
|
|
|
157
|
<h3>col time</h3> |
|
158
|
|
|
159
|
This function is a proxy for sqlite3's |
|
160
|
<tt>[http://www.sqlite.org/lang_datefunc.html|strftime()]</tt> function. It is used like this: |
|
161
|
|
|
162
|
|
|
163
|
<nowiki><pre> |
|
164
|
query $stmt col time $index {%Y%m%d @ %H:%M:%S} |
|
165
|
</pre></nowiki> |
|
166
|
|
|
167
|
Any remaining arguments are treated as "modifiers" and passed as-is to strfmtime. For example: |
|
168
|
|
|
169
|
<nowiki><pre> |
|
170
|
query $stmt col time $index {%Y%m%d @ %H:%M:%S} {+5 years} |
|
171
|
query $stmt col time $index %s unixepoch |
|
172
|
</pre></nowiki> |
|
173
|
|
|
174
|
|
|
175
|
|
|
176
|
|
|
177
|
<h2>strftime</h2> |
|
178
|
|
|
179
|
This works like <tt>col time</tt> (described below) but takes its |
|
180
|
value from an arbitrary source specified by the 3rd argument. |
|
181
|
|
|
182
|
<nowiki><pre> |
|
183
|
query strftime %s 1319211587 unixepoch |
|
184
|
query strftime {%Y%m%d @ %H:%M:%S} [query $stmt col string 2] {+10 years}] |
|
185
|
</pre></nowiki> |
|
186
|
|
|
187
|
<h2>Global Variables</h2> |
|
188
|
|
|
189
|
This API installs the following global variables, all of which correspond to |
|
190
|
<tt>SQLITE_xxx</tt> constant values: |
|
191
|
|
|
192
|
* <tt>SQLITE_BLOB</tt> |
|
193
|
* <tt>SQLITE_FLOAT</tt> |
|
194
|
* <tt>SQLITE_INTEGER</tt> |
|
195
|
* <tt>SQLITE_NULL</tt> |
|
196
|
* <tt>SQLITE_TEXT</tt> |
|
197
|
|
|
198
|
These values are used only by the <tt>col type</tt> function. They can be |
|
199
|
accessed from script code via <tt>$::SQLITE_xxx</tt>. |
|
200
|
|