On Mon, Sep 8, 2025 at 12:13 PM Mohammad Nejati <ashtumashtum@gmail.com> wrote:
On Mon, Sep 8, 2025 at 12:35 PM Dominique Devienne via Boost <boost@lists.boost.org> wrote:
I think maybe people don't realize that SQLite is an *embedded* DB engine. The very term resultset is misleading. There's no resultset type in SQLite, like there is in PostgreSQL's LIBPQ for example. The term resultset give the impression the result of a query is "materialized" somehow. It's NOT!
Yes, I think the problem boils down to the fact that a resultset is tied to a statement, and trying to make it an owning type causes confusion around lifetime management and gives the false impression that multiple resultsets can exist for a single statement. It might be better to merge the functionality of resultset to statement and leave resultset as a reference type that is constructible from a statement (and possibly rename it to resultset_ref). This way, usages like the following will remain possible without having to pass a statement& around: void print(std::ostream &os, sqlite::resultset rw)
[sqlite3pp][1] has a statement class, that's the base abstract wrapper, adding RAII and typesafety (and overloading to drive higher abstractions). And separate command and query derived concrete classes, with "streaming" getters and "setters" (to bind) as syntax sugar. i.e. there's no resultset at all. The "statement" remains the only object. There are more types on the query side, to support foreach loops, but not in a way that blur the real picture with a made-up resultset. Yes, it's an old wrapper that hasn't kept pace. It's more abstraction are closer to the reality of SQLite IMHO. FWIW. PS: BTW, there's no such thing as named-binding in SQLite per-se. There's binding-by-index, and an API to get the index of a placeholder name. So basically name-binding is always more "overhead". I never used it... Smaller API surface too, unlike what sqlite3pp does, and I suspect Klemens'. [1]: https://github.com/iwongu/sqlite3pp/blob/master/src/sqlite3pp.h