Boost logo

Boost :

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2024-03-25 11:24:55


On Mon, Mar 25, 2024 at 11:59 AM Julien Blanc via Boost <
boost_at_[hidden]> wrote:

> Le dimanche 24 mars 2024 à 00:51 +0800, Klemens Morgenstern via Boost a
> what's making the proposed boost.sqlite different from existing libraries?
> It's not so clear to me. I see two things that are not widespread:
>
> * variant-base interface
>

SQLite has it's own opaque internal variant (call value).
https://www.sqlite.org/c3ref/value.html

I'd expect an SQLite wrapper to wrap that, instead of using std::variant or
boost::variant2.
Which does not prevent interop with those variants, but that's a separate
topic.

> * json support
>

SQLite has built-in support for JSON. https://www.sqlite.org/json1.html
It used to be a pure extension, but nowdays it's backed in,
even in the grammar to support PostgreSQL like -> and ->> operators.

No need for Boost.JSON. What I'd like to see OTOH, is an example of the
library
that duplicates the behavior of JSON1 using Boost.JSON, to demonstrate the
ease
of writing a virtual-table module with the proposed library, with a bunch
of table-valued functions.
That should outperform JSON1, if Boost.JSON is has fast as it is supposed
to be.

As Julien already wrote, there are many SQLite C++ wrapper libraries.
but I'm not aware of any that tackles virtual tables. That would be the
standout feature IMHO.
One that's hard-code and in keeping with Boost's tradition of pushing the
envelop.

Another example of integration with v-tables and Boost.MultiIndex would
also be very Boost like.
Wiring up the v-table to leverage the various indexes of the BMIs in
xBestIndex is non-trivial.
These are the kind of advanced features and demos that would make a
Boost-based SQLite wrapper shine IMHO. --DD


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk