On Mon, 25 Aug 2025 at 14:53, Mohammad Nejati [ashtum] via Boost <boost@lists.boost.org> wrote:
Boost.SQLite provides a safer and more expressive C++ interface to the SQLite3 C-API to simplify usage and reduce errors.
- What is your evaluation of the design?
This library is minimal, by design - but this needs to be considered in the context of the stated goal to reduce errors and simplify usage. I have some reservations. . It does (successfully) provide access to each of the facilities in SQLite3, to allow them to be used in an idiomatic manner (from a C++ perspective). The way this is done reduces opportunities for errors compared to direct use of the C API by providing basic RAII resource management of individual SQLite3 resources. It uses owning pointers with custom resources in encapsulating individual sqlite resource types (eg statements). On the other hand it appears to leave plenty of opportunity for footguns. Im not convinced some of these at least couldn't be eliminated, without a significant performance impact and with better, not worse, usability. The convenience and general ergonomics of the interface provided is fine: Treating the result of executing a statement as a range Ranges for access to the fields (columns) of results Conversions of individual column value types to and from idiomatic C++ eg scalar types and string_view Extending this to typed access rowset columns as tuples (position) or (described, pre C++20) struct field names Importantly, it provides a non-exception based way of reporting results.(and they genuinely are often results not "exceptions" so this is in general necessary and is enough to dissuade this user at least from using alternatives that provide only a throwing interface. It is disappointing that this is in conflict with some of the idiomatic usage features - iterators in particular. I'm also concerned that by providing a single class that allows for both a "sqlite3 way" and a "idiomatic C++ way" that mixed usage can create object states that are unexpected. Rather than saying "don't do that" why not prevent that through distinct types?
- What is your evaluation of the implementation? It's clean and minimal, well structured.
- What is your evaluation of the documentation? Inadequate regarding the concepts above. I'm all for relying on sqlite3 documentation for a lot of detail - but this does not mean that one should have to assume or read the implementation to determine how the interface presented by the library operates.
The examples show only basic, throwing, and non-RAII breaking usage of the library. And don't attempt to handle any unexpected results.
- What is your evaluation of the potential usefulness of the library?
It is very useful, because sqlite3 is incredibly useful, and making it easier to use and usage consistent and correct would be a boon.
Do you already use it in industry?
No but I use sqlite3.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
I had no problems building and using the library using gcc 14.2.1 and boost 1.87 and sqlite 3.47.2 I built and ran the tests and examples and made some modifications to the examples to try things out.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A few hours. Which was enough for a reasonable depth of review given the relative simplicity of the library.. I did not look at the virtual table and extension support beyond looking at and running the examples and a brief review of the implementation. I do consider the support for these facilities to be important and useful - and this library is the best effort I have seen in making these facilities easier to use.
- Are you knowledgeable about the problem domain?
Somewhat. I'm not a huge user of sqlite, but have over the years written C++ and other language interfaces/bindings for diverse "databases" with fairly raw C APIs e.g as diverse as lmdb and MS ODBC./ SQL server.
At the end of your review, please state clearly whether you ACCEPT, REJECT, or CONDITIONALLY ACCEPT (with explicit conditions) the proposed Boost.SQLite library.
I recommend acceptance of this library only on the condition it has some footguns removed and any remaining better and clearly documented. I view the footgun removal as more than just idiot proofing. This domain demands treating all results equally. The problems that exist nin error handling would be mitigated by having a type able to indicate the result was an error without resorting to separate reference "out" parameters. Allowing closing and re-connecting the connection creates a conflict with RAII concepts - a 2 stage (but only once) initialisation (ie late connection, but no re-initialisation) would seem sufficient for satisfactory ergonomics. Serious consideration should be given to extending the lifespan of depended on, underlying, objects (statement, specifically, depended on by result) - this is likely a practical necessity for the deferred evaluation of error vs result described above. I've leapt into the review / conclusion "early" given the relatively short window - I would be happy to discuss this feedback - this isn't intended as a drive-by review...