/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-23 09:17:03 UTC
  • Revision ID: edam@waxworlds.org-20100723091703-3siqjj6eeux9hupz
- added NEWS
- added library checks to configure.ac
- added query::iterators
- remove dependency that rows have on querys (since querys have to be dependent on rows for boost::iterator_facade to work)
- rows now have the handle to the sqlite3 statement and know a count of their row number
- added convenience function tht can be used to detect presence of sqlite3cc in other packages
- updated test-main
- renamed all subdir.mk files to emake.mk

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
 
 
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
 
 
 
1
- expand sqlite_error - perhaps use boost::system_error (see boost/asio/error.hpp for an example of extending system_error)
 
2
- use sqlite3_db_mutex() to provide extended error information during sqlite_error construction - see sqlite::query::step() for example
 
3
- see if we can #include "sqlite.h" in to a namespace.
56
4
        Pros:
57
 
         - we better encapsulate the library
58
 
         - we can reuse "sqlite3" as a namespace
 
5
                we better encapsulate the library
 
6
                we can reuse "sqlite3" as a namespace
59
7
        Cons:
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
 
8
                makes access to real sqlite stuff awkward to sqlite3cc users, but does this matter? they can't access database._handle anyway!
 
9
                potential incompatibility when linking to libraries that also link against sqlite
 
10
- add immediate_transaction
 
11
- fix step() inconsistency - query::step() returns a row, whereas basic_statement::step() and command::step() return an int return code
 
12
- fix row/query compilation dependency issue. break dependency of querys on rows
 
13
        - can't use "row"s in the iterator
 
14
        - could wrap rows, and use dereference operator to access
 
15
        - could use a base class, which wouldn't cause extra dereferences in use and shouldn't have much overhead (no vfpt)
 
16
        - look at the boost::iterator_facade interface - can we switch to "row *"s?
 
17
- query::prepare() isn't being called during construction (form
 
18
        basic_statement's constructor)