1
- check that the fix for in-progress queries during rollback is threadsafe. In
2
particular, we shouldn't be resetting queries from another thread! Does
3
sqlite3_next_stmt() only return statements from this thread?
5
- turn on extended errcodes in open() and handle them in sqlite_error
7
- make basic_statement and database keep a shared pointer to the database handle
8
so the classes can be made copyable. The wrappers around the handle
9
(implemented in sqlite::detail) can clean them up after use. This will also
10
make the implementation of rows (to get round the forced non-dependency of
11
rows on querys) a little easier to swallow.
12
- A similar wrapper should be created for statement handles, making
13
basic_statements, querys and commands copyable. Could weak_ptrs to these
14
also be used in the database's list active querys?
16
- add columns() to row that returns a boost::tuple of various types so multple
17
columns can be fetched at once (look in to using BOOST_PP_ITERATE macro)
19
- use sqlite3_db_mutex() to provide extended error information during
20
sqlite_error construction. The general procedure would be to lock the db
21
mutex, perform some sqlite3 command, check the error code, throw an
22
sqlite_error (whilst obtaining extended error info) and then unlock the db
24
- a macro would be simple
4
- look in to making query and command's _handle a shared_ptr, so that query
5
and command classes can be copied.
7
- rename _bind_index and _column_index to _next_*
9
- change the transaction_guard interface so you can dereference it to get to
10
its transaction and the transactions take care of not rolling back or
11
committing when they already have done (as well as resetting in-progress
14
- turn on extended errcodes in open() and handle them in sqlite_error
16
- query::prepare() isn't being called during construction (from
17
basic_statement's constructor)
19
- add columns() to row that returns a boost::tuple of various types so multple
20
columns can be fetched at once (look in to using BOOST_PP_ITERATE macro)
22
- add a row::column() that can take a column name. This is nexessary when
23
doing a "SELECT *" and you don't know the column indicies. To implement
24
this, the first time it is called, a column-name-to-index lookup would have
25
to be built. This should be done in the query, not the row. This means that
26
the row will have to know it's query (currently is copies its _handle) to be
27
able to call column_index() on it. Is this a problem?
29
- use sqlite3_db_mutex() to provide extended error information during
30
sqlite_error construction. The general procedure would be to lock the db
31
mutex, perform some sqlite3 command, check the error code, throw an
32
sqlite_error (whilst obtaining extended error info) and then unlock the db
34
- a macro would be simple
25
35
- a templated safe-calling object (passing the comman's arg types as
26
template params) may be overkill
28
- expand sqlite_error - perhaps use boost::system_error (see
29
boost/asio/error.hpp for an example of extending system_error)
31
- see if we can #include "sqlite.h" in to a namespace.
36
template params) may be overkill
41
- make basic_statement and database keep a shared pointer to the database
42
handle so the classes can be made copyable. The wrappers around the handle
43
(implemented in sqlite::detail) can clean them up after use. This will also
44
make the implementation of rows (to get round the forced non-dependency of
45
rows on querys) a little easier to swallow.
46
- A similar wrapper should be created for statement handles, making
47
basic_statements, querys and commands copyable. Could weak_ptrs to these
48
also be used in the database's list active querys?
50
- expand sqlite_error - perhaps use boost::system_error (see
51
boost/asio/error.hpp for an example of extending system_error)
53
- see if we can #include "sqlite.h" in to a namespace.
33
we better encapsulate the library
34
we can reuse "sqlite3" as a namespace
56
- we better encapsulate the library
57
- we can reuse "sqlite3" as a namespace
36
makes access to real sqlite stuff awkward to sqlite3cc users, but does
37
this matter? they can't access database._handle anyway!
38
potential incompatibility when linking to libraries that also link
41
- query::prepare() isn't being called during construction (form
42
basic_statement's constructor)
59
- makes access to real sqlite stuff awkward to sqlite3cc users, but does
60
this matter? they can't access database._handle anyway!
61
- potential incompatibility when linking to libraries that also link
added
removed
TODO
