bzr branch
http://bzr.ed.am/sqlite3cc
|
17
by edam
- failed to update TODO in last commit |
1 |
|
2 |
IMMEDIATE ISSUES |
|
3 |
||
4 |
- rename _bind_index and _column_index to _next_* |
|
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
5 |
|
|
11
by edam
- update TODO |
6 |
- 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 |
7 |
|
|
17
by edam
- failed to update TODO in last commit |
8 |
- query::prepare() isn't being called during construction (form |
9 |
basic_statement's constructor) |
|
|
15
by edam
- fixed error caused by finialising in-progress queries during rollback that were later finaliased by RAII. |
10 |
|
11 |
- add columns() to row that returns a boost::tuple of various types so multple |
|
12 |
columns can be fetched at once (look in to using BOOST_PP_ITERATE macro) |
|
13 |
||
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
14 |
- 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?) |
15 |
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 |
16 |
mutex, perform some sqlite3 command, check the error code, throw an |
17 |
sqlite_error (whilst obtaining extended error info) and then unlock the db |
|
18 |
mutex. Two options: |
|
19 |
- a macro would be simple |
|
20 |
- a templated safe-calling object (passing the comman's arg types as |
|
21 |
template params) may be overkill |
|
22 |
||
|
17
by edam
- failed to update TODO in last commit |
23 |
|
24 |
LONGER TERM IDEAS |
|
25 |
||
26 |
- make basic_statement and database keep a shared pointer to the database handle |
|
27 |
so the classes can be made copyable. The wrappers around the handle |
|
28 |
(implemented in sqlite::detail) can clean them up after use. This will also |
|
29 |
make the implementation of rows (to get round the forced non-dependency of |
|
30 |
rows on querys) a little easier to swallow. |
|
31 |
- A similar wrapper should be created for statement handles, making |
|
32 |
basic_statements, querys and commands copyable. Could weak_ptrs to these |
|
33 |
also be used in the database's list active querys? |
|
34 |
||
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
35 |
- expand sqlite_error - perhaps use boost::system_error (see |
36 |
boost/asio/error.hpp for an example of extending system_error) |
|
37 |
||
|
9
by edam
- added NEWS |
38 |
- see if we can #include "sqlite.h" in to a namespace. |
39 |
Pros: |
|
40 |
we better encapsulate the library |
|
41 |
we can reuse "sqlite3" as a namespace |
|
42 |
Cons: |
|
|
13
by edam
- made basic_statement::step() protected, for use by query and command only |
43 |
makes access to real sqlite stuff awkward to sqlite3cc users, but does |
44 |
this matter? they can't access database._handle anyway! |
|
45 |
potential incompatibility when linking to libraries that also link |
|
46 |
against sqlite |