Re: [review] [sqlite]

From: Дмитрий Архипов (grisumbras_at_[hidden])
Date: 2024-11-19 08:45:34

пт, 15 нояб. 2024 г. в 15:58, Klemens Morgenstern
<klemensdavidmorgenstern_at_[hidden]>:
> Would you also suggest automatic conversions or just stick to sqlite::value ?

To be honest, I'm not sure. Automatic conversions would also have to
rely on deduction, which would again inhibit the use of templates and
overloaded functions.

> I think you're right. I didn't really like the context idea in your
> previous code example, but I think this can be rectified: instead of a
> context object, you can pass in a tuple that gets forwarded to the
> constructor of the function.
> ...
> create_aggregate_function<collect_libs, 1>("my-prefix", 42);

First, I realised that there's no need to put any additional shared
data into SQLite-managed memory, as you can always just add a
reference member to the callable and store that shared data on your
side.

Second, I assume the point of this approach is to avoid copying the
callable object, and also support non-default constructible callables.
My approach uses the original callable as a kind of prototype, from
which it copies new objects for every operation. To be honest, I don't
think there should be any difference in performance between my
approach with copying and yours with constructing. Ergonomically, I
think mine is better. Yours may be looking more straightforward to
users.

One idea came to my mind. It's sometimes hard to determine which parts
of the SQLite C API are supported by your library, and what specific
components do it. So, I think you need a dedicated list of all SQLite
C functions with comments like "supported via sqlite::backup",
"supported via sqlite::mutex", "not supported because an analogous
function X is supported ", "not supported because deprecated by
SQLite", etc.