/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: 2010-07-27 15:46:42 UTC
  • Revision ID: edam@waxworlds.org-20100727154642-1uxrjkpxhp7xl6hq
- moved null_t, exec_t and set_index_t to detail namespace so only their extern instantiations are in the main namespace
- added immediate transation

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
 
2
 
IMMEDIATE ISSUES
3
 
 
4
 
- rename _bind_index and _column_index to _next_*
5
 
 
 
1
- add columns() to row that returns a boost::tuple of various types so multple columns can be fetched at once
 
2
        - look in to using BOOST_PP_ITERATE macro
 
3
- make basic_statement and database keep a shared pointer to the database handle so the classes can be made copyable. Also:
 
4
        - the wrappers around the handle can clean them up after use
 
5
        - the actual wrappers wround the handles can be made in sqlite::detail
 
6
        - this will also make the implementation od rows (to get round the forced non-dependency of rows on querys) a little easier to swallow.
 
7
- committing a transaction during a query (i.e., when sqlite3_step() has returned SQLITE_ROW) causes an error. To counter this:
 
8
        - need to check it's not fixed in latest sqlite; write test program
 
9
        - calling query.reset() before the commit fixes the issue
 
10
        - will need to keep a list of querys that need resetting in the database  :o(
6
11
- 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
20
 
        - a templated safe-calling object (passing the comman's arg types as
21
 
                template params) may be overkill
22
 
 
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
 
 
35
 
- expand sqlite_error - perhaps use boost::system_error (see
36
 
        boost/asio/error.hpp for an example of extending system_error)
37
 
 
 
12
- use sqlite3_db_mutex() to provide extended error information during sqlite_error construction - see sqlite::query::step() for example
 
13
- expand sqlite_error - perhaps use boost::system_error (see boost/asio/error.hpp for an example of extending system_error)
38
14
- see if we can #include "sqlite.h" in to a namespace.
39
15
        Pros:
40
16
                we better encapsulate the library
41
17
                we can reuse "sqlite3" as a namespace
42
18
        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
 
19
                makes access to real sqlite stuff awkward to sqlite3cc users, but does this matter? they can't access database._handle anyway!
 
20
                potential incompatibility when linking to libraries that also link against sqlite
 
21
- fix step() inconsistency - query::step() returns a row, whereas basic_statement::step() and command::step() return an int return code
 
22
- query::prepare() isn't being called during construction (form
 
23
        basic_statement's constructor)