/sqlite3cc

To get this branch, use:
bzr branch http://bzr.ed.am/sqlite3cc

« back to all changes in this revision

Viewing changes to TODO

  • Committer: edam
  • Date: 2012-01-23 13:51:26 UTC
  • Revision ID: edam@waxworlds.org-20120123135126-7gohm0mv9qwismla
typo

Show diffs side-by-side

added added

removed removed

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