Easy iteration and conversion of data rows.

[jtv]

No description provided.

[jtv]

There's a separate step for string_view conversion, since that's a special case. There is no general conversion to string_view, since there's no way to return a "self-contained" string_view. There's just a few special cases where we can make guarantees about the lifetime of the backing storage.

…

On Sun, Jan 30, 2022, 06:56 Kirit Sælensminde ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In test/unit/test_result_iteration.cxx <#528 (comment)>: > + // Use for_each with a lambda closure. + std::string names{}; + int total{0}; + + res.for_each([&names, &total](std::string name, int salary){ + names.append(name); + total += salary; + }); + PQXX_CHECK_EQUAL(names, "xyz", "result::for_each did not accumulate names correctly."); + PQXX_CHECK_EQUAL(total, 1000 + 1200 + 1500, "Salaries added up wrong."); + + // In addition to regular conversions, you can receive arguments as + // string_view, as well as references. + names.clear(); + total = 0; + res.for_each([&names, &total](std::string name, int salary){ Should the std::string here be a std::string_view? — Reply to this email directly, view it on GitHub <#528 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYDE5TRGQN4EVOJJIFERTUYTHIZANCNFSM5NDKLDDA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[KayEss]

That contradicts the comment in the line above, and if it is meant to be a std::string, that appears to make the test identical to the one a bit further up.

[jtv]

That contradicts the comment in the line above, and if it is meant to be a std::string, that appears to make the test identical to the one a bit further up.

I had made some changes to that comment since the version you looked at, so it's possible that the contradiction has disappeared.

The general idea is: there are no "regular" string conversions to string_view, but streaming queries and result sets do support them as special cases.

[jtv]

I had made some changes to that comment since the version you looked at, so it's possible that the contradiction has disappeared.

Actually, I see now that the wrong comment is still there. It's possible that the correction is still sitting on my laptop unpushed. Fixing.

[jtv]

So it works nicely. But I'm still not sure this is a good idea. I mean, how actually useful is it? It doesn't ever save you having to name the types, doesn't reduce type stutter — unless you already happen to have a callback in function form, or you just really prefer specifying the types there.

[KayEss]

Personally I always feel that functional code looks better than imperative, so for me this looks like a nice API. To adapt from your test, I'd expect it to look like this in an application:

tx.exec("SELECT name, salary FROM employee ORDER BY name").for_each(
    [&](std::string_view name, int salary) {
        names.append(name);
        total += salary;
    });

This looks pretty clean to me, and an improvement over a raw for loop with explicit casts -- so I'd certainly use it.

[jtv]

Personally I always feel that functional code looks better than imperative, so for me this looks like a nice API. To adapt from your test, I'd expect it to look like this in an application:

Thanks for the feedback @KayEss. I tried some alternate spellings using the existing API but nothing was significantly better than for_each, at least.

I think I'll continue this work then. But I feel compelled to do the same for streaming queries, which leaves me with some other template puzzles to solve.