sob., 13 wrz 2025 o 17:44 Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> napisał(a):
On Sat, Sep 13, 2025, 7:19 PM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
sob., 13 wrz 2025 o 10:28 Klemens Morgenstern via Boost < boost@lists.boost.org> napisał(a):
Having a deeper look at SQLite, I now realize that you actually cannot
work
with two statements on one connection concurrently (this is not related to multi-threading):
That would be news to me. Can you be a bit more specific about what you mean by "cannot"?
Maybe I should have made that a question rather than a statement. Would the following concurrent use of two statements work without any resource-management issues?
``` auto query1 = conn.prepare("select * FROM table1"); auto query2 = conn.prepare("select * FROM table2");
auto combined = std::views::zip(statement_range<T1>(query1),
statement_range<T2>(query2));
for (auto record: combined) process(record); ``` ("Concurrent" in the sense that I progress over the second statement without having finished with the first one.)
Yes.
Thank you. This was my mistake, of using Copilot as an assistant in investigations. So, looking at this page from SQLite manual -- https://www.sqlite.org/c3ref/stmt.html -- a statement (or stmt or prepared statement) represents the "life cycle" of a compiled procedure: creation/preparation, binding parameters, performing steps, resetting, finalizing. I have some reflections that I can't help sharing. 1. Maybe you do not need the name "prepare". I think that it is implied by the nature of a statement that the only way to get a non-trivial instance of one is to do the preparation by passing the string command and connection. So maybe: sqlite::statement stmt = conn.statement("select * from CLIENTS"); 2. It looks to me that even at this point I could decide whether I will be observing rows from a table, and what types these rows will have: sqlite::statement<tuple<string, int>> stmt = conn.statement<tuple<string, int>>("select NAME, AGE from CLIENTS;"); Am I right about this? I think that no "reset" can change the row type of a once compiled statement. 3. In this scheme where sqlite::statement is parametrized, we would have `statement<void>` for just instructions that do not have any rows and `statement<aggregate>` for reading "rows". In this case there is no harm in providing the range interface directly in `statement<aggregate>`. Is there ever a need to delay or change the decision on how we want to view the rows of a once compiled statement? Regards, &rzej;