/sqlite3cc : revision 18

1

2

IMMEDIATE ISSUES

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

20

- a templated safe-calling object (passing the comman's arg types as

21

template params) may be overkill

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

22

36

23

37

24

38

LONGER TERM IDEAS

25

39

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.

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

39

56

Pros:

40

we better encapsulate the library

41

we can reuse "sqlite3" as a namespace

57

- we better encapsulate the library

58

- we can reuse "sqlite3" as a namespace

42

59

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

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