/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: Tim Marston
  • Date: 2014-01-03 16:39:17 UTC
  • Revision ID: tim@ed.am-20140103163917-pv80n7ial8zbavh2
Tags: 0.1.1
bump version no. to 0.1.1; fixed indentation in NEWS

Show diffs side-by-side

added added

removed removed

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