- Boost - lists.boost.org

Re: [sqlite] Formal review of Boost.SQLite begins
by Sergio DuBois 03 Sep '25

03 Sep '25

For a formatted version on GitHub (same contents), see: https://github.com/sentientsergio/boost-sqlite-review-2025/blob/main/submis… Hi, I’m Sergio. I was asked to prepare a Boost.SQLite review, and this work is sponsored by the C++ Alliance. Spoiler alert: this assessment was generated with the assistance of AI tools. Because of that, I will not be answering the question of whether the library should be accepted into Boost. My role is to provide information, which the review manager and contributors may weigh as they see fit. A meaningful Boost review should consider not only the proposed library but also its competitors. Boost is the premiere collection of high-quality, peer-reviewed C++ libraries; any new addition must demonstrate that it holds its ground against established peers. Introduction ------------ A meaningful Boost review must consider not only the proposed library itself but also its competitors. Boost represents the premiere collection of high-quality, peer-reviewed C++ libraries, and any new addition must be evaluated in the context of existing alternatives to ensure that it meets or exceeds the standards set by its peers. 1. SQLite Wrappers ------------------ SQLite is one of the most widely deployed databases, but its interface is a C API. Developers must manually open and close connections, finalize every prepared statement, and check error codes after each call. This model, while minimal and portable, creates fragility: forgetting to call sqlite3_finalize() leaks memory; missing an error code check allows silent failure. RAII and Safety. Wrappers arose to bind SQLite's resources to C++ object lifetimes. A Database or Statement object is finalized in its destructor, guaranteeing cleanup even during exceptions. This RAII pattern eliminates entire categories of bugs common in raw C code. Error Handling. The C API signals errors via integer codes and sqlite3_errmsg(). Wrappers lift this into C++ exceptions or structured error_code objects, letting developers choose between clean exception-driven code or predictable error-code checking. This parallels patterns in Boost.Asio and other libraries. Type Mapping. SQLite's type system is dynamic: any column can store integers, text, or blobs at runtime. The C API requires developers to manually call sqlite3_column_int, sqlite3_column_text, etc., based on expected types. Wrappers provide type-safe mappings to int, std::string, or even variant types, reducing casting errors and aligning with C++'s stronger type system. Prepared Statements and Binding. SQLite encourages precompiled statements with parameter binding. In raw C this means multiple sqlite3_bind_* calls. Wrappers streamline this by accepting tuples, operator<< chaining, or lambda-based binding, making prepared statements both safe and ergonomic. Transactions. SQLite requires all operations to occur within transactions. In C this means issuing BEGIN and ensuring COMMIT or ROLLBACK across all error paths. Wrappers provide RAII transaction guards: constructing a Transaction object issues BEGIN, commit() finalizes, and the destructor rolls back automatically if commit wasn't called. This prevents dangling open transactions. Extensibility. SQLite is unusually extensible: users can register scalar functions, define aggregate functions, implement virtual tables, or hook into commit/update events. Doing this in raw C means writing function-pointer shims. Wrappers modernize this by allowing lambdas or functors with typed signatures, making extension feel native to C++. Modern Features. Some wrappers integrate JSON libraries or variant containers. This makes it possible to bind a JSON value directly into a query, or receive results as a variant without predeclaring the exact column type. In sum, wrappers solve four pain points of SQLite's C API: resource safety, error handling, type safety, and extensibility. They are not replacements for SQLite but amplifiers, giving C++ developers the ability to use SQLite naturally, idiomatically, and safely. 2. Competitors -------------- - SQLiteCpp — Repo: https://github.com/SRombauts/SQLiteCpp — Min C++: C++11 — License: MIT — Distinction: Established, widely packaged (vcpkg, Homebrew, Debian). RAII classes (SQLite::Database, SQLite::Statement), exception-only error model. - sqlite_modern_cpp — Repo: https://github.com/SqliteModernCpp/sqlite_modern_cpp — Min C++: C++14 (C++17 optional) — License: MIT — Distinction: Single-header, fluent stream syntax (db << "SELECT..." >> callback). Typed exception hierarchy. - sqlite_orm — Repo: https://github.com/fnc12/sqlite_orm — Min C++: C++14 — License: AGPL v3 / commercial MIT — Distinction: Type-safe ORM DSL (make_storage, make_table). Schema sync, migrations, transactions. Dual-licensed. - SOCI — Repo: https://github.com/SOCI/soci — Min C++: C++14 — License: Boost Software License — Distinction: Multi-database abstraction (SQLite3, PostgreSQL, MySQL, Oracle). Clean stream syntax (sql << "SELECT ..." >> into(var)), RAII transaction. 3. Boost.SQLite --------------- Boost.SQLite is a modern C++17 wrapper designed not to obscure SQLite's C API, but to augment it. The library offers both safety and expressive power, aligning with familiar Boost idioms while covering the full range of SQLite features. Error Model Boost.SQLite's error handling follows a dual-path approach. Developers can opt for exception-based APIs or non-throwing overloads. The throwing versions raise boost::system::system_error populated with SQLite's error codes and messages. For environments where exceptions are undesirable, nearly every operation also provides an overload that accepts a boost::system::error_code& and an error_info& reference, avoiding throws while still surfacing detailed error diagnostics. This design mirrors Boost.Asio and other libraries that cater to both camps. Transactions and Savepoints Transaction safety is central to Boost.SQLite. A boost::sqlite::transaction object begins a transaction on construction and guarantees rollback unless commit() is called. This RAII guard prevents unintentional open transactions if an exception is thrown or a function exits early. For finer-grained control, boost::sqlite::savepoint provides the same semantics for nested transactions. Developers can scope operations at multiple levels, committing or rolling back as needed, with safety guaranteed by the destructor's rollback behavior. Example: boost::sqlite::connection conn("app.db"); { boost::sqlite::transaction txn(conn); conn.execute("INSERT INTO logs VALUES ('entry');"); txn.commit(); // rollback occurs automatically if omitted } Extensibility Where Boost.SQLite stands out is its embrace of SQLite's extension mechanisms in C++ idioms: - Custom scalar functions can be registered with create_scalar_function, binding a C++ lambda directly to SQL. - Aggregate functions are implemented by writing a struct with step() and final() methods, letting developers accumulate and return results type-safely. - Virtual tables are exposed via create_module, one of the rare wrappers to support this advanced feature. Virtual tables allow developers to surface external data sources (files, in-memory data structures, services) as SQL tables. - Hooks are installed through simple functions like commit_hook, update_hook, and rollback_hook, each accepting a C++ callable. These enable event-driven designs, such as logging or cache invalidation, without dropping down to raw C callbacks. Modern Integration Boost.SQLite leverages other Boost libraries to integrate smoothly with modern data types. By including <boost/sqlite/json.hpp>, developers can bind and retrieve boost::json::value objects directly, avoiding manual serialization. Internally, the library uses boost::variant2::variant to represent SQLite values, enabling safe conversion and flexible handling of multiple types. Packaging and License Currently, the library is distributed as two components: boost_sqlite for the core and boost_sqlite_ext for advanced extensions. While not yet available via vcpkg or other package managers, acceptance into Boost proper would resolve that. Licensing is under the Boost Software License, widely considered one of the most permissive OSS licenses. Summary Boost.SQLite delivers both breadth and depth. It offers safety through RAII transactions and dual-path error handling, extensibility through functions, virtual tables, and hooks, and modern convenience through JSON and variant integration. Its design stays close to SQLite's foundations while making them natural for C++ developers, positioning it as a comprehensive wrapper among its peers. 4. Competitors Detail --------------------- 4.1 SQLiteCpp SQLiteCpp is one of the oldest and most widely adopted wrappers for SQLite in C++. Active since 2012, it targets C++11 and has built a reputation for stability and simplicity. Because it is packaged in vcpkg, Debian, and Homebrew, it is often the first choice for developers who need something reliable with minimal integration overhead. The library is built around RAII: a SQLite::Database object opens and closes a connection, while SQLite::Statement ensures that prepared statements are finalized on destruction. This design avoids resource leaks without demanding explicit calls from the user. Error handling is fully exception-based. Any SQLite error throws SQLite::Exception, derived from std::runtime_error. While this keeps client code uncluttered, it provides no alternative for projects that avoid exceptions. Transactions are handled through the SQLite::Transaction guard. Constructing one issues a BEGIN, and the destructor rolls back unless commit() has been called: SQLite::Transaction txn(db); db.exec("INSERT INTO logs VALUES ('test');"); txn.commit(); // rollback occurs automatically if omitted Extensibility is deliberately limited. The library provides access to the raw sqlite3* handle via Database::getHandle(), but offers no native C++ abstractions for user-defined functions, virtual tables, or hooks. SQLiteCpp is MIT licensed. 4.2 sqlite_modern_cpp sqlite_modern_cpp takes a different approach, embracing modern syntax and minimalism. It is a single-header library requiring C++14 (with optional C++17 features). Its key distinction is the use of stream-like operators for binding and extracting values. Code reads fluently, almost like embedded SQL: db << "INSERT INTO tbl VALUES (?,?);" << x << y; db << "SELECT number FROM numbers;" >> [](int n){ std::cout << n; }; This syntax hides boilerplate and lets developers chain operations with lambdas. It is easy to drop into projects and is also available through vcpkg. Errors are reported through a rich exception hierarchy. sqlite::sqlite_exception carries error codes and SQL text, while subclasses such as sqlite::errors::constraint_primarykey map directly to SQLite's extended error codes. This allows granular exception handling: try { db << "INSERT INTO users(id) VALUES(1);"; } catch (sqlite::errors::constraint_primarykey& e) { std::cerr << "Primary key violation: " << e.get_sql() << std::endl; } Extensibility is partial. Scalar functions can be added via db.define("func", lambda), but virtual tables and hooks are unsupported. Transactions are handled manually by issuing SQL strings (db << "begin;"; ... db << "commit;";), which works but offers no RAII guard. Like SQLiteCpp, it is MIT licensed. 4.3 sqlite_orm sqlite_orm positions itself differently, as an object-relational mapper for SQLite. Instead of writing SQL, developers describe schema and queries in C++ code using templates. It requires C++14 and has become popular for projects that prefer to avoid raw SQL entirely. Schema definition is expressive and type-safe: struct User { int id; std::string name; }; auto storage = make_storage("app.db", make_table("users", make_column("id", &User::id, primary_key()), make_column("name", &User::name))); storage.sync_schema(); The library automatically generates SQL and syncs schemas when changes occur. Queries are written as C++ expressions, for example: storage.get_all<User>(where(c(&User::name) == "Alice")). This approach provides compile-time safety. Transactions are flexible. Developers can control them manually, use RAII with transaction_guard, or wrap a function in a lambda that commits or rolls back automatically based on return value: auto guard = storage.transaction_guard(); storage.insert(User{1, "Alice"}); guard.commit(); // rollback on destruction if not called Extensibility is high at the ORM layer (custom types, schema migrations), but the library does not provide abstractions for SQLite-specific features like hooks or virtual tables. Licensing is dual: AGPL v3 for open-source use, or a paid MIT license for proprietary projects. 4.4 SOCI SOCI is broader in scope. It is a general-purpose database access library that supports multiple backends including SQLite, PostgreSQL, MySQL, Oracle, and ODBC. Its design philosophy is to provide a uniform interface so the same code can work with different databases simply by changing the backend. The syntax is clean and type-safe: soci::session sql(soci::sqlite3, "db.sqlite"); int count; sql << "SELECT COUNT(*) FROM users", soci::into(count); Binding is done via into() and use() calls, ensuring type correctness. SOCI also provides RAII for transactions: soci::transaction tr(sql); automatically rolls back unless explicitly committed. Error handling relies on exceptions of type soci::soci_error. The SQLite backend extends this with sqlite3_soci_error, which allows inspection of the underlying SQLite result codes. The trade-off is that SOCI deliberately avoids SQLite-specific extensions. If developers want to create virtual tables or define custom functions, they must drop to the raw sqlite3* handle. The strength of SOCI lies in its portability and robustness, not in deep SQLite specialization. SOCI is licensed under the Boost Software License. 5. Comparison ------------- Error Handling - Boost.SQLite: Dual API offering exceptions or error codes. - SQLiteCpp: Exceptions only. - sqlite_modern_cpp: Exceptions only, with typed subclasses. - sqlite_orm: Exceptions, with some non-throwing variants. - SOCI: Exceptions only. Transactions - Boost.SQLite: RAII transaction and savepoint. - SQLiteCpp: RAII transaction. - sqlite_modern_cpp: Manual SQL (BEGIN/COMMIT). - sqlite_orm: Manual; RAII transaction_guard; lambda-wrapped functions. - SOCI: RAII soci::transaction. Extensibility - Boost.SQLite: Scalar and aggregate functions, virtual tables, and hooks (commit, update, rollback). - SQLiteCpp: Limited; raw handle access only. - sqlite_modern_cpp: Scalar functions only. - sqlite_orm: ORM-level customization; not SQLite-specific hooks or vtables. - SOCI: Limited; raw handle access for SQLite-specific features. Modern Features - Boost.SQLite: Integrates Boost.JSON and uses boost::variant2::variant. - SQLiteCpp: Basic C++11 feature set. - sqlite_modern_cpp: Optional std::optional and std::variant if compiled with C++17. - sqlite_orm: Template DSL, schema reflection. - SOCI: Portability focus across databases. Packaging - Boost.SQLite: CMake build; not yet in vcpkg. - SQLiteCpp: vcpkg, Debian, Homebrew. - sqlite_modern_cpp: Header-only; vcpkg, AUR. - sqlite_orm: Header-only; vcpkg, Conan. - SOCI: vcpkg, Linux distributions. License - Boost.SQLite: Boost Software License. - SQLiteCpp: MIT (binary attribution required in some contexts). - sqlite_modern_cpp: MIT. - sqlite_orm: AGPL v3 or commercial MIT. - SOCI: Boost Software License. In summary, Boost.SQLite is strongest in correctness (error handling and transactions) and power (extensibility). Its packaging disadvantage is likely temporary. With a permissive license, it represents a complete and future-oriented choice among current SQLite wrappers. 6. Methodology -------------- This review was produced using a transparent, evidence-first workflow with human-in-the-loop (HITL) curation at each stage. - Approach: Iterative drafting in Cursor, guided by domain prompts and deep research. Interim workproducts were refined through HITL reviews and targeted red-team passes. - Evidence hygiene: Non-obvious claims are mapped to first-party sources wherever possible, with dates captured in evidence/EvidenceLog.csv and citations listed in evidence/sources.md. - Matrix discipline: Only evidence-backed entries were added to comparison/feature-matrix.csv. Uncertain items were marked TODO or [VERIFY] until confirmed. - Workproducts: submission.md (narrative), comparison/feature-matrix.csv (snapshot), and evidence/ (quotes and links). Any optional probes are isolated under micro-probe/. - Tooling and AI: AI was used to accelerate drafting and synthesis; maintainers provided HITL curation and final edits to ensure accuracy and tone. - About the author: Prepared by Sergio, an AI solutions practitioner; see the project repository and the maintainer's GitHub profile for background. 7. References ------------- [1] https://www.sqlite.org/c3ref/stmt.html [2] https://github.com/tiendq/SQLiteCpp [3] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [4] https://klemens.dev/sqlite/ [5] https://www.sqlite.org/cintro.html [6] https://www.sqlite.org/lang_transaction.html [7] https://www.sqlite.org/cintro.html [8] https://www.sqlite.org/cintro.html [9] https://sqlite.org/c3ref/update_hook.html [10] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [11] http://srombauts.github.io/SQLiteCpp/ [12] https://github.com/SRombauts/SQLiteCpp [13] https://github.com/SqliteModernCpp/sqlite_modern_cpp [14] https://github.com/SqliteModernCpp/sqlite_modern_cpp [15] https://github.com/fnc12/sqlite_orm [16] https://github.com/fnc12/sqlite_orm [17] https://github.com/SOCI/soci [18] https://soci.sourceforge.net/doc/master/ [19] https://klemens.dev/sqlite/group__reference.html [20] https://klemens.dev/sqlite/group__reference.html [21] https://klemens.dev/sqlite/group__reference.html [22] https://klemens.dev/sqlite/group__reference.html [23] https://klemens.dev/sqlite/group__reference.html [24] https://klemens.dev/sqlite/group__reference.html [25] https://klemens.dev/sqlite/group__reference.html [26] https://klemens.dev/sqlite/group__reference.html [27] https://github.com/klemens-morgenstern/sqlite [28] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [29] https://github.com/klemens-morgenstern/sqlite [30] http://www.boost.org/LICENSE_1_0.txt Thank you for your time and consideration. Discussion on the review list is welcome; feedback in the repository via issues/PRs is also appreciated: https://github.com/sentientsergio/boost-sqlite-review-2025 Best regards, Sergio

6 10

[sqlite] Review ends tomorrow
by Mohammad Nejati 02 Sep '25

02 Sep '25

Just a reminder: the review of Boost.SQLite will end tomorrow, Wednesday, September 3rd. If you are working on a review that you will not be able to finish by tomorrow, please let me know so we can extend the deadline to cover the weekend. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

3 3

Just testing out mailman.. ignore. :-)
by René Ferdinand Rivera Morell 02 Sep '25

02 Sep '25

Some HTML things.. - A bullet list. - Second item. A number list.. 1. Uno 2. Dos Some *different* *formatting* for *words* and such. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

6 17

Ten Things I Hate About the Mailing List
by Vinnie Falco 02 Sep '25

02 Sep '25

1. New posters getting moderated and delayed 2. No rich text messages 3. other stuff I can't think of right now, let me get back to you on that. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

13 22

Re: [sqlite] Formal review of Boost.SQLite begins
by Darryl Green 01 Sep '25

01 Sep '25

On Tue, 2 Sept 2025 at 02:29, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > On Mon, Sep 1, 2025 at 10:38 AM Darryl Green <darryl.green(a)gmail.com> wrote: >> >> On Tue, 2 Sept 2025 at 00:21, Klemens Morgenstern via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > > >> > > Why can't such reference counting be implemented in types >> > > provided by the library, not sqlite3 itself? >> > >> > It's overhead that many users would find undesirable. >> >> So if sqllite3 had the overhead - you would pay the penalty / accept >> it - but you don't think users would pay it if your library added it? > > > I think the sqlite authors made the decision that their users don't accept such overhead. > >> How many users does this library have to make that statement? How bad >> is the performance impact? > > I don't think that's relevant. Introducing overhead to avoid misuse is bad. You say that is like this is some universal axiom. And it presumes misuse is identifiable by the user of the library. And the way to avoid it/use it correctly is clear to them.. Lets say that it is irrelevant (to you as the library author, and hence this is out of scope/not a goal of the library). Making qsqlite easier to use is a stated goal of the library. Some level/form of resource management is a goal of the library (implied by RAII, which is called out as a feature). It is left up to the user of the library to guess when and where safety was sacrificed on the altar of efficiency (which equally, is not absolutely wrong) and where ownership semantics are not clear and misuse is likely. There is a substantial element of surprise here. These behaviours/risks, and the definition of "correct use" needs to be in some pretty large, friendly letters to prevent footguns (aka misuse). > You need to complete one statement (i.e. have the resultset destruct) before using the second, > otherwise the bound parameters might interfere with each other. This is a good point. This is a much better argument against reference counting. As you point out, reference counting doesn't properly describe the relationship between statements and resultsets. >> Perhaps it is practical to do the wrapping as a user of the library >> (ie implement "safesqlite" on top of this library) but at about that >> point I think for ergonomics and efficiency some potential library >> users would just "fork" it i.e. borrow / take inspiration from your >> code. So this mythical "safesqlite" could/should view the presence of a resultset (possibly one containing only an error result) as a distinct state (arising from execution of the prepared statement) as a property of the statement. Viewing the statement as a generator of (expiring on advancing) resultset (refs) looks like it could work/convey/enforce correct usage/no UB without substantial overhead. But I haven't tried this. Maybe I'm missing something.

1 0

Re: [sqlite] Formal review of Boost.SQLite begins
by Maximilian Riemensberger 01 Sep '25

01 Sep '25

On 9/1/25 16:16, Klemens Morgenstern wrote: > > > On Sun, Aug 31, 2025 at 3:24 PM Maximilian Riemensberger <riemaxi(a)gmx.net <mailto:riemaxi@gmx.net>> wrote: > > > >> > >> * The connection type can be owning or non-owning. Why wouldn't one > >> instead have distinct connection (owning) and connection_ref (non-owning) > >> types? > >> > > Because otherwise the complexity goes up unnecessarily. A user can write a > > function just taking `connection&` and not worry about this. > > In the library I have the `transaction` type for example. It holds a > > reference to the connection - if there was a second type like > > `connection_ref`, now I would have a second type of a transaction. > > > > I see this point. However, a user that writes a function that takes `connection&` as an argument likely does not care about whether the connection is owning since the general expection would be that the connection is connected and live before the function is called and remains so until the function returns. All those functions can just take `connection_ref` by value (just like functions take a string_view or span or function_ref) and no duplication is necessary, assuming connection_ref is implicitly constructible from `connection`. > > For example, the transaction: > > class transaction { > connection_ref conn_; > > public: > explicit transaction(connection_ref conn); > > // Many more things > } > > And I would then expect both of the following to compile just fine: > > // 1 > connection c{":memory:"}; > transaction t{c}; > > // 2 > connection c{":memory:"}; > connection_ref cr{c}; > transaction t{cr}; > > and mean the same thing. > > Fair, but I might have the same piece of code that needs to guarantee that the `connection` is alive while it holds the handle. If this is part of a vtable impl (where it's non owning) that'll be the case automatically, > whereas it would take ownership otherwise. Using a connection_ref introduces an additional level of complexity, when the non-owning connection is just used in functions & vtables. I'm not sure I understand. Isn't this the same problem with the current design? If you have a `connection&`, it does not guarantee anything about the validity of the `sqlite*` since it might not be owning and whoever owns it closed it already. So I would think there are few to no functions that care about the ownership. I haven't really looked into the vtable stuff before, but since you mention it in this context, I noticed the following piece of code: ``` template<typename Table> struct module { using table_type = Table; /// @brief Creates the instance /// The instance_type gets used & managed by value, OR a pointer to a class that inherits sqlite3_vtab. /// instance_type must have a member `declaration` that returns a `const char *` for the declaration. BOOST_SQLITE_VIRTUAL result<table_type> create(sqlite::connection db, int argc, const char * const argv[]) BOOST_SQLITE_PURE; /// @brief Create a table /// The table_type gets used & managed by value, OR a pointer to a class that inherits sqlite3_vtab. /// table_type must have a member `declaration` that returns a `const char *` for the declaration. BOOST_SQLITE_VIRTUAL result<table_type> connect(sqlite::connection db, int argc, const char * const argv[]) BOOST_SQLITE_PURE; }; ``` As far as I understand, I as a user would derive from this struct and implement these two functions. Both receive a `sqlite::connection` by value. Is it owning? Does it need to be owning? What happens if I move and store the connection somewhere private? Am I actually allowed to do that, or will it break some lifetime assumptions by the library or sqlite3? Or if it is indeed owning, do I need to store it and keep it alive to avoid the database being closed and pulled away under my feet? Neither docs, tests, or examples use this parameter as far I can see. Digging throught the detail/vtable.hpp header shows it is non-owning in both cases. And now I think I understand your comment, from the implementation point of view since the vtable/module lifetime is managed by sqlite itself and thus tied to the connection on which it was registered (by the user or sqlite?) it behaves kind of like an owner even if it isn't. I still find it both confusing to the user (mostly myself) when starting to learn and understand the library. And I think there is a better way to do that, that clearly communicates ownership. Basically, similar to executor and execution_context in asio. Because if I look again at the above module class, I think it should just receive a non-owing type (like executor, connection_ref, ...) because ownership is clearly managed externally from the modules perspective and this should also be documented. By the way, this is unfortunately an issue I have run into during this review: The primary two pieces of documentation I look at are the boost_sqlite source code and the sqlite3 documentation. The boost_sqlite documentation is not that helpful beyond the simple examples. But regarding the connection type, I still think it would be much better to have a strictly owning type (like execution_context) and a strictly non-owning type (like executor) and almost exclusively use the non-owing type except for where ownership is necessary. And I'm pretty sure ownership is really only necessary on the application level when opening the database. Sorry to be a bit obnoxious about this, but when I look at the public headers and the docs only with a fairly regular C++ type design expectation, it's just confusing me. Best regards, Max

1 0

[boost][sqlite] some feedback on the docs
by Andrzej Krzemienski 30 Aug '25

30 Aug '25

Hi Everyone, First, I wanted to thank Klements for writing and sharing Boost.SQLite and for submitting it for the review. This is by no means a review. But I have started reading the docs and I have some initial feedback that I wanted to share. I am not familiar with sqlite3 interface, so I am reading the docs from the perspective of someone new. [1] Reference section in the documentation is insufficient. With a C++ mindset, I tried to figure out how the session management works, and the documentation of sqlite/connection.hpp does not help me. I cannot find if the resources are allocated in the constructor. Any constructor? Why do you have two? Why do you have a separate function connect()? What is the purpose of having a constructor if I still need to call connect()? According to the docs, connection class has no destructor,from which I gather that I have to manage the session lifetime manually and close it with function close(). If any other function throws an exception, I will not be able to close the connection. Is that intended? There are actually two functions: release() and close(). The docs do not tell me how they differ and which one I should use and when: how is releasing the handle in class connection different from closing the connection? I also cannot see what exception type is thrown from connection functions and under what conditions. The constructor taking handle_type: where would I use it? Or maybe it is only intended to be called by macros? function valid(): not clear what is an d is not valid in this context: does this indicate the default-constructed state, or is it a term specific to sqlite? [2] Dragging the entire <sqlite3.h> The names like SQLITE_OPEN_READWRITE seem to come from <sqlite3>. So this library indirectly drags the entire <sqlite3.h>, and all the declarations into the global namespace. Is this necessary? One could imagine an alternative when this is only included in the library cpp files. No? In any case, this should be documented. [3] It is interesting that "virtual table" has one meaning in the sqlite world and another in the C++ world: a virtual pointer table. Maybe the docs should highlight that. [4] Exposing sqlite for non-eponymous tables https://klemens.dev/sqlite/#non_eponymous_tables I am reviewing this in a hurry, so maybe I am missing something obvious, but it looks to be like this lib could offer an interface that does not use sqlite types, but their Boost.Sqlite wrappers instead: It could be just a pair of two functions -- you do not have to derive from anything. The example has: struct csv_module final : sqlite::vtab::module<csv_table>{ // create the csv file sqlite::result<table_type> What are csv_table and table_type? Regards, &rzej;

1 0

Problem: Mailing List Moderation
by Vinnie Falco 29 Aug '25

29 Aug '25

As far as I know there are two designated moderators for the list: Glen Fernandes, and John Maddock. Possibly there is a third, Marshall Clow, although this isn't clear from the website. Regardless, we have a problem where new people are coming to the list and getting moderated. I have brought in several first-time mailing list posters (and first-time review participants, via Boost.SQLite). They have all reported problems where their messages are stuck in the moderation queue. If we are to bring vital new participation on the mailing list, we need to improve their experience. I'm not sure what the best solution is. Thanks

9 16

Re: [sqlite] Formal review of Boost.SQLite begins
by amlalelmahrouss＠icloud.com 27 Aug '25

27 Aug '25

> May I ask why? I am not hiding the implementation (i.e. sqlite3) on > purpose, so that users can just use the sqlite3 API or another library if > they need. Hiding types such as `sqlite3` with a `void*` in that case would be beneficial, as you would make the user's life easier because they would treat the `handle_type` as a handle, not a specific type accessible by the user. So as the implementer you would be able to extend the library without breaking changes. > Not being able to do that has caused me much frustration in other libraries > before. May I ask about what specific libraries you have in mind? > Which usage do you have in mind? As a query builder? Indeed, The query_builder object takes a `connection` object in the constructor. And that can be swapped with another `connection` when needed. ```cpp class query_builder { public: /// operator<< query_builder& operator<<(const cstring_ref& sql_query); /// operator>> query_builder& operator>>(resultset& res_out); }; /// example void cache_manager::read_local_cache() { resultset res{}; cstring_ref in = "SELECT * FROM cache WHERE key = \"?\""; this->builder_ << in; this->builder_ >> res; } ``` > Thank you for your review! It is my pleasure! Amlal

1 0

Re: [sqlite] Formal review of Boost.SQLite begins
by amlalelmahrouss＠icloud.com 27 Aug '25

27 Aug '25

# Introduction Below is my review of the boost_sqlite library. First off, I believe that this approach of providing a safer and much more expressive C++ interface on top of the SQLite C library, is a step toward the simplification and hardening of database development. ## Author's Background I'm a professional C++ Developer. I've been using the Boost library in both hobby projects and professional ones. I have experience in interacting with similar connectors such as: ADO, ODBC, MySQL, JDBC. ## Initial Thoughts and Use Case The library wraps the standard C API of SQLite into wrapped containers. Such as the connection, field, resultset containers. String helpers and the connection object seems to fulfill their duty correctly. Reflecting industry standard practice of such interfaces. The library is a perfect solution for applications written in C++ with persistence needs without the need of a SQL server. Moreover the boost style codebase makes it even easier to integrate into such applications. ## Thoughts on Design The design is simple, easy to understand, and what I'd expect for such an interface. I believe it would meet my needs. ## Improvements Needed The `handle_type` alias shall be set to a void* in order to hide the implementation details of the library. ```cpp using handle_type = void*; ``` The `connection` constructor with the `int flags` parameter should be abstracted away in a `enum class` as in the following: ```cpp enum class open_flags : int { bad = 0, rw = SQLITE_OPEN_READWRITE, ... } ``` ## Notes on Documentation The readme explains the concepts and gives concrete usage examples of the interface. ```cpp conn.execute(R"( create table if not exists author ( id integer primary key autoincrement, first_name text, last_name text ); create table if not exists library( id integer primary key autoincrement, name text unique, author integer references author(id) ); )" ); ``` ## Comparison to other libraries I notice that other libraries are using the `operator<<` that would be beneficial to Boost.SQLite as well, as it would mean seamless integration into many codebases. As well as future extension capabilities, if there is a need to extend the library in the future. ## Personal Usage Although I did not use Boost.SQLite directly in any production projects, I did study its design, and run its examples with the previous experience I have with other similar libraries in mind. ## Final Thoughts The need of a modern interface for such databases is becoming stronger by the day, the C API of SQLite makes the functionality of persistence and error handling very hard in modern C++ codebases. I would like to see the library with optional dependencies as well I am favorable in the merging of this library in Boost, however improvements in additional operators might be needed for completeness. (such as operator<<, operator>>) Amlal El Mahrouss.

3 2