Start 8 Composite part III

[pkfox]

A continuation of Part II as that is getting too long
I can't add a tag or label to my own issue because I'm not part of a triage ! FFS git / Microsoft

[pkfox]

@jtv All gone quiet here on the encoding front have we hit a dead end ?

[jtv]

I had no idea, I thought you could add your own labels to github tickets.

Sorry for the radio silence — need to mind my health. I have been able to reproduce the "Tried to read text without knowing its encoding" error in a test (it's a pqxx::argument_error)) by calling composite_into_buf() with a std::source_location as the first argument. You should definitely pass a pqxx::conversion_context there, not a source_location.

But, in your case it does sound as if the "bucket chain" of passing the conversion_context got broken somewhere else as well, and the problem is I can't see into your code to determine the call stack above composite_into_buf(). That's where the other error comes from: "Tried to parse array/composite without knowing its text encoding" (which is a pqxx::usage_error). It's also why it can be helpful to know that source_location that gets reported inside the exception.

By the way, I think I'll make composite_into_buf() return a zview. That's an inconvenient change for you right now, but it'll probably mean slightly less code for you overall. And, more importantly, less opportunity for mistakes with the terminating zero.

[pkfox]

By the way, I think I'll make composite_into_buf() return a zview. That's an inconvenient change for you right now, but it'll probably mean slightly less code for you overall. And, more importantly, less opportunity for mistakes with the terminating zero.

What will I have to change the return value of to_buf

[jtv]

In to_buf() you can just return the pqxx::zview you get back from composite_into_buf() directly.

So no more need to subtract 1 or construct a string_view. That all gets done for you now.

[jtv]

You can try the change in branch composite-1100. It's PR #1110.

[pkfox]

You can try the change in branch composite-1100. It's PR #1110.

So it isn't in start8 ? Because I'm all setup to pull and rebuild that
It's composite-1108 @jtv building as I write this

[jtv]

Urrrgh. Found a deep, dark corner where it's difficult to pass a conversion context: statement parameters!

If you're passing a WorldeAnswer as a parameter to an SQL statement, then in that context the parameters code needs to know the encoding. And that's a fairly painful API change.

[pkfox]

Urrrgh. Found a deep, dark corner where it's difficult to pass a conversion context: statement parameters!

If you're passing a WorldeAnswer as a parameter to an SQL statement, then in that context the parameters code needs to know the encoding. And that's a fairly painful API change.

Well I don't know what you've done but parse_composite now works

WordleAnswer wa;

std::string raw_attempts;
std::string level_text;
try
{
    parse_composite(
        utils::GetCtx(),
        text,
        wa.id,
        wa.Answer,
        wa.Wordledate,
        wa.Solved,
        wa.Notes,
        level_text,
		wa.Attemptslist, // This is the vector of strings
        wa.Amenddate
    );

}

[pkfox]

@jtv The only thing I've done which might of inadvertently helped is, my data access class used to have a pqxx::work class member and I got rid of it in favour of creating a local tx whenever I need it

[jtv]

That sounds like the right choice and it wouldn't have affected this.

It's amazing how much it can help to keep data structures and functions shallow. Even if it means juggling more objects and functions at the top.

[pkfox]

That sounds like the right choice and it wouldn't have affected this.

It's amazing how much it can help to keep data structures and functions shallow. Even if it means juggling more objects and functions at the top.

@jtv So it was definitely something you did that seems to have fixed parse_composite - it compiled ok before but threw a runtime error it seems fine now