Re: [boost] boost.sqlite seeking endorsement

Sent from my iPad

On 23 Mar 2024, at 17:51, Klemens Morgenstern via Boost wrote:

On Sat, Mar 23, 2024 at 7:49 PM Vinnie Falco wrote:

...

...

On Fri, Mar 22, 2024 at 10:51 PM Daniela Engert via Boost wrote:

I wouldn't characterise that as 'unreasonable' - others obviously feel the same. Because of that, a library with such capabilities that already exists: https://github.com/rbock/sqlpp11.

That is a beautiful library but I still maintain that the original request, type-safe SQL strings (and constexpr at that) is unreasonable.

The library you linked does not use SQL strings at all, it has its own EDSL. It is not actually SQL (which represents database queries using a string) but rather "sql-flavored" C++ API. Julien wanted this:

prepare("insert into author (first_name, last_name) values (?1, ?2), (?3, ?4), (?5, ?6), (?7, ?8)");

to be type-safe. Doing so would require parsing the SQL string. It is this which is unreasonable as it is reinventing the parser from sqlite.

It's not very useful either. Yes, you could check if an argument is missing, but you can never know if a query is valid at runtime, e.g. if the `author` table exists can only ever be checked at runtime. And on top of that, missing an input argument is not an error in sqlite - it's just null.

...

I have to ask an obvious question, why didn't the author of proposed Boost.Sqlite just start with one of these mature libraries? This sqlpp11 looks very nice, comparable to soci if not better.

I think that's because you have multiple tasks that are often done by different libraries in multiple languages.

In the lowest layer (1) you have the specific database client (e.g. boost.mysql), on layer 2 a generic database client (e.g. SoCi), then a query builder on layer 3 (e.g. sqlpp11) and then you usually have ORMs in layer 4, when you have reflection in the language.

I see a depressing recurrence in the boost mailing list whenever someone takes the trouble to solve a real world problem and then propose that solution for inclusion in boost. The question asked by Klemens was for endorsement. He has received two positive responses. The rest of the responses are along the lines of: “You didn’t solve some other problem.” “You didn’t solve an imaginary non-problem.” “I wouldn’t have done it that way.” Of course you wouldn’t have done it that way. For the vast majority, you wouldn’t have put yourself out there, used your own time and selflessly proposed the library to the community in the first place. I would like to see less “why not X, I prefer Y” responses in the mailing list and more focus on the question as asked. The review is the place for finding _real_ problems with the library design, based on actually _using_ the offered library. Using the mailing list as a peanut gallery to punish innovation is distasteful and rude. If you have a different library to propose, the floor is open. High quality submissions to boost are welcome.

boost.sqlite would be strictly layer (1) so it can support sqlite specific features. A generic database client would be great, too, especially when built on top of boost.mysql and boost.sqlite, but that's just not what boost.sqlite tries to be. So I don't see either library as contenders. The actual contenders are other sqlite client libraries in C++ and I list some in the readme.

I don't think it's helpful to compare this proposed library to generic sql clients or query builders, just like it wouldn't have been helpful to compare boost.beast to python requests.

Peter pointed out that it might be a good idea to add some side to side comparison of using sqlite with using my library and he's correct since this does not seem apparent. But that's the problem this library tries to solve.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost