/sqlite3cc

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