/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:12:55 UTC
  • Revision ID: edam@waxworlds.org-20100727151255-goaqgdz4kj13q7gz
- update TODO
- added some missing includes for <string>
- changed usage of database::exec() to not require return code!
- prevented transaction_guard destructor from throwing an exception

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
- add columns() to row that returns a boost::tuple of various types so multple
2
 
        columns can be fetched at once (look in to using BOOST_PP_ITERATE macro)
3
 
 
4
 
- make basic_statement and database keep a shared pointer to the database handle
5
 
        so the classes can be made copyable. The wrappers around the handle
6
 
        (implemented in sqlite::detail) can clean them up after use. This will also
7
 
        make the implementation of rows (to get round the forced non-dependency of
8
 
        rows on querys) a little easier to swallow.
9
 
        - A similar wrapper should be created for statement handles, making
10
 
                basic_statements, querys and commands copyable. Could weak_ptrs to these
11
 
                also be used in the database's list active querys?
12
 
 
13
 
- fix to force the finalisation of queries in progress for transactions causes
14
 
        errors; queries are now finalised twice, the second from basic_statement's
15
 
        dtor, which causes a segfault. We could:
16
 
        - keep a list of force-finalised sqlite3_stmt pointers in the database which
17
 
                we use to check queries against before finalising them to make sure we
18
 
                don't finalise them a second time
19
 
                - an efficient implementation, but not very OO
20
 
        - keep a map of active queries in the database (using the sqlite3_stmt
21
 
                pointer as the key), so that we can obtain the query and tell it to
22
 
                finalise its self
23
 
                - this seems like a messy and complicated implementation
24
 
 
 
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
- move _null_t, _exec_t and _set_index_t to sqlite::detail. Only the named instantiations of these structs need be in the sqlite namespace.
 
8
- add immediate_transaction
 
9
- committing a transaction during a query (i.e., when sqlite3_step() has returned SQLITE_ROW) causes an error. To counter this:
 
10
        - calling query.reset() before the commit fixes the issue
 
11
    - need to check it's not fixed in latest sqlite
 
12
    - will need to keep a list of querys that need resetting in the database  :o(
25
13
- turn on extended errcodes in open() and handle them in sqlite_error
26
 
 
27
 
- use sqlite3_db_mutex() to provide extended error information during
28
 
        sqlite_error construction. The genreeal procedure would be to lock the db
29
 
        mutex, perform some sqlite3 command, check the error code, throw an
30
 
        sqlite_error (whilst obtaining extended error info) and then unlock the db
31
 
        mutex. Two options:
32
 
        - a macro would be simple
33
 
        - a templated safe-calling object (passing the comman's arg types as
34
 
                template params) may be overkill
35
 
 
36
 
- expand sqlite_error - perhaps use boost::system_error (see
37
 
        boost/asio/error.hpp for an example of extending system_error)
38
 
 
 
14
- use sqlite3_db_mutex() to provide extended error information during sqlite_error construction - see sqlite::query::step() for example
 
15
- expand sqlite_error - perhaps use boost::system_error (see boost/asio/error.hpp for an example of extending system_error)
39
16
- see if we can #include "sqlite.h" in to a namespace.
40
17
        Pros:
41
18
                we better encapsulate the library
42
19
                we can reuse "sqlite3" as a namespace
43
20
        Cons:
44
 
                makes access to real sqlite stuff awkward to sqlite3cc users, but does
45
 
                        this matter? they can't access database._handle anyway!
46
 
                potential incompatibility when linking to libraries that also link
47
 
                        against sqlite
48
 
 
 
21
                makes access to real sqlite stuff awkward to sqlite3cc users, but does this matter? they can't access database._handle anyway!
 
22
                potential incompatibility when linking to libraries that also link against sqlite
 
23
- fix step() inconsistency - query::step() returns a row, whereas basic_statement::step() and command::step() return an int return code
49
24
- query::prepare() isn't being called during construction (form
50
25
        basic_statement's constructor)