bzr branch
http://bzr.ed.am/sqlite3cc
2
by edam
- further initial development |
1 |
- expand sqlite_error - perhaps use boost::system_error (see boost/asio/error.hpp for an example of extending system_error) |
9
by edam
- added NEWS |
2 |
- use sqlite3_db_mutex() to provide extended error information during sqlite_error construction - see sqlite::query::step() for example |
3 |
- see if we can #include "sqlite.h" in to a namespace. |
|
4 |
Pros: |
|
5 |
we better encapsulate the library |
|
6 |
we can reuse "sqlite3" as a namespace |
|
7 |
Cons: |
|
8 |
makes access to real sqlite stuff awkward to sqlite3cc users, but does this matter? they can't access database._handle anyway! |
|
9 |
potential incompatibility when linking to libraries that also link against sqlite |
|
10 |
- add immediate_transaction |
|
11 |
- fix step() inconsistency - query::step() returns a row, whereas basic_statement::step() and command::step() return an int return code |
|
12 |
- fix row/query compilation dependency issue. break dependency of querys on rows |
|
13 |
- can't use "row"s in the iterator |
|
14 |
- could wrap rows, and use dereference operator to access |
|
15 |
- could use a base class, which wouldn't cause extra dereferences in use and shouldn't have much overhead (no vfpt) |
|
16 |
- look at the boost::iterator_facade interface - can we switch to "row *"s? |
|
17 |
- query::prepare() isn't being called during construction (form |
|
18 |
basic_statement's constructor) |