Using mod_sqlite
mod_sqlite allows you to access your SQLite database over HTTP. To do
this, the Location that you have configured mod_sqlite to use will take
query parameters that allow the user to query the database. Here is a
list of those parameters, and what they do:
|
'db'
|
-- The 'db' parameter specifies what file the SQLite database
resides in. mod_sqlite will attempt to read from the file specified
by this parameter.
|
| 'q' |
-- The 'q' parameter specifies what SQL query should be executed.
|
| 'p' |
-- The 'p' parameter specifies the value of a bind parameter to use.
|
Usage examples:
To query the database '/tmp/foo.txt' with the SQL 'select * from test', the
query would look like this:
http://localhost/test?db=/tmp/foo.txt&q=select+*+from+test
To query the same database, but use bind parameters with the statement
'select * from test where name = %Q and id = %Q' where name equals 'Aaron'
and id equals '1' would look like this:
http://localhost/test?db=/tmp/foo.txt&q=select+*+from+test+where+name+%3D+%25Q+and+id+%3D+%25Q&p=Aaron&p=1
The query string looks complicated, but it is just the SQL statement URI
encoded. Just URI encode the data to send to mod_sqlite. mod_sqlite will
support GET's as well as POST's, so your data can be longer than a GET
will support.
Return values:
After executing a query, mod_sqlite will return the results URI encoded
and separated by semicolons. The first line of the results will always
be the column names corresponding to the data. Each row is separated by
a newline. A result set might look something like this:
id;name;password
1;Aaron;1234
2;Bill;secret
Error handling:
If any errors occur mod_sqlite will set a special header in the HTTP
response called 'X-SQLite-Error'. 'X-SQLite-Error' will contain the error
that SQLite threw.
