Re: [review] [sqlite]

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-11-19 09:20:46

On Tue, Nov 19, 2024 at 5:05 PM Ruben Perez <rubenperez038_at_[hidden]> wrote:

> On Tue, 19 Nov 2024 at 09:37, Klemens Morgenstern
> <klemensdavidmorgenstern_at_[hidden]> wrote:
> >
> >
> >
> > On Tue, Nov 19, 2024 at 4:30 PM Ruben Perez <rubenperez038_at_[hidden]>
> wrote:
> >>
> >> What's the best way to specify a nullable field in the static
> >> interface? std::optional<T> and boost::optional<T> don't seem to work,
> >> nor does having a sqlite::field member.
> >
> >
> > sqltie:;value would work. I should add optional support though.
>
> It doesn't seem to work. Apparently, some part of the machinery
> requires the row type to be default-constructible, making
> sqlite::value unusable in that context.
>

Yes, that's a bug in the way the static_result is implemented.
I wanted to not use index_sequences and all that fun stuff to make this
fast, but that now requires default-constructibility.

>
> Anyway, sqlite::field explicitly states it's for query results, while
> sqlite::value is for usage in internal APIs. This is holding the
> results of a query, so why is it sqlite::value the one that looks to
> be supported?
>

The logic was that the static_result strips the column/row/table
information and just gives you a value.
The equivalent here would be the value instead of the field.
But if I add optional (and maybe variant) support I should probably remove
that.