pon., 8 wrz 2025 o 11:05 Dominique Devienne via Boost <boost@lists.boost.org> napisał(a):
* I did not find any design documentation or rationale for the library's design decisions regarding ownership handling of sqlite3 resources.
Most reviewers have disclosed they don't have much experience with SQLite. This shows on this point. You often don't own the main connection object. Large and old code bases using SQLite have different subsystems, written by different people, each wanting to use its favorite flavor of SQLite. And that includes heavy weights like Qt and its Sql "module". We even have to use our own Qt SQLite Driver to be able to inject a connection owned by lower layers of our code.
So my point is essential to recognize that Boost.SQLite, if it arrives at all, arrives very late, and has to integrate with the messy reality of own grown and OSS wrappers, sometimes on the *same* connections. And as Klemens wrote, you don't have to have to duplicate APIs you can into, or templatize them, just because the connection is owning or not.
Whether the RAII or not the connection is the client-code's choice. And most code shouldn't care at all, and just use it.
This is a very important point. And somewhat incompatible with what Boost.SQLite docs say. The framework returning a handle to connection is not the only motivation for having a non-owing connection. Another, as you say, is the user already employing another library that does the resource management. This would mean that a `connection_ref` class (if Boost.SQLite takes that route) needs to have a constructor (apart from one taking `connection`) taking the `sqlite3*` parameter. Regards, &rzej;