/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-29 20:56:19 UTC
  • Revision ID: edam@waxworlds.org-20100729205619-a9yo4uzu647nvnsj
- renamed database to connection to better identify what it is (would database_connection be better though?)
- moved basic_statement and basic_transaction to sqlite::detail
- made sqlite::threadsafe() return the threading mode int, not a bool
- renamed row::index() to row_number() so it isn't confused with column index
- added typedef for deferred_transaction
- added early rollback method to transaction_guard
- allowed transaction_guard::~transaction_guard() to throw exceptions, since when it needs to, we're really screwed anyway
- bugfix: query::reset() didn't reset the internal row counter
- added query::num_results()
- added docs/design-notes
- reimplemented query::iterator so that increment() (which performs a step() on the query) now caches the returned row to be returned during dereference() (previously it stashed details and returned new row!?)
- bugfix: resetting active queries during rollbacks would hang!

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
 
2
 
IMMEDIATE ISSUES
3
 
 
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
 
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
35
25
        - a templated safe-calling object (passing the comman's arg types as
36
 
      template params) may be overkill
37
 
 
38
 
 
39
 
LONGER TERM IDEAS
40
 
 
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
 
 
 
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.
55
32
        Pros:
56
 
         - we better encapsulate the library
57
 
         - we can reuse "sqlite3" as a namespace
 
33
                we better encapsulate the library
 
34
                we can reuse "sqlite3" as a namespace
58
35
        Cons:
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
 
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)