bzr branch
http://bzr.ed.am/sqlite3cc
|
16
by edam
- renamed database to connection to better identify what it is (would database_connection be better though?) |
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? |
|
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
4 |
|
|
11
by edam
- update TODO |
5 |
- turn on extended errcodes in open() and handle them in sqlite_error |
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
6 |
|
|
15
by edam
- fixed error caused by finialising in-progress queries during rollback that were later finaliased by RAII. |
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? |
|
15 |
||
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) |
|
18 |
||
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
19 |
- use sqlite3_db_mutex() to provide extended error information during |
|
16
by edam
- renamed database to connection to better identify what it is (would database_connection be better though?) |
20 |
sqlite_error construction. The general procedure would be to lock the db |
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
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 |
|
23 |
mutex. Two options: |
|
24 |
- a macro would be simple |
|
25 |
- a templated safe-calling object (passing the comman's arg types as |
|
26 |
template params) may be overkill |
|
27 |
||
28 |
- expand sqlite_error - perhaps use boost::system_error (see |
|
29 |
boost/asio/error.hpp for an example of extending system_error) |
|
30 |
||
|
9
by edam
- added NEWS |
31 |
- see if we can #include "sqlite.h" in to a namespace. |
32 |
Pros: |
|
33 |
we better encapsulate the library |
|
34 |
we can reuse "sqlite3" as a namespace |
|
35 |
Cons: |
|
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
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 |
|
39 |
against sqlite |
|
40 |
||
|
9
by edam
- added NEWS |
41 |
- query::prepare() isn't being called during construction (form |
42 |
basic_statement's constructor) |