Clear db connection after database error

[heyrutvik]

Closes #3342

[heyrutvik]

The build is failed because of this. I'm not seeing any clippy errors in local but will make changes as per the build log.

[heyrutvik]

@weiznich There is a table definition in the connection.rs file which could be moved to the relevant test method. I don't see a reason to keep it outside. The test I added encloses table definition within it which is inspired from other test cases, example.

@seeekr has made a suggestion that we can move that table definition to the relevant test method (and other similar pattern in the codebase, if any) using following changeset to keep the changes minimal,

fn managing_updated_at_for_table() {

    table! {
        #[sql_name = "auto_time"]
            auto_time_table {
            id -> Integer,
            n -> Integer,
            updated_at -> Timestamp,
        }
    }

    use auto_time_table::dsl::{auto_time_table as auto_time, n, updated_at};
    ...

Initially, I made changes to enclose that table definition, different from this, but it was cluttering the actual changes. I have reverted it to push only changes relevant to the ticket. Let me know your thoughts about it, whether we want to include such changes in current PR or in a separate one.

[weiznich]

Thanks for filling this PR 👍
This looks already good, but I feel that we should act a bit more careful here in terms of error propagation.

[weiznich]

We want to return the orginal error here, so we want to avoid using ? at all. Something like

Suggested change

	while conn.get_next_result()?.is_some() {}
	while conn.get_next_result().map(Option::is_some).unwrap_or(true) {}

(although this will recursively call the same function (PgResult::new) again and potentially run this loop there again. I believe that should be fine as this should stop at some layer wen get_next_result() returns None)

[heyrutvik]

@weiznich Is the default value true intended? Wouldn't it keep the loop running even after some error? Am I missing something?

This is fine if even after error only if we know for sure that subsequent get_next_result calls will definitely return None at some point. I think you are also saying the same thing in the brackets, right?

[weiznich]

Yes true is the correct default value as far as I can tell. The libpq documentation states that PQgetResult (which is called internally by this function) must be called till it returns null. It does not talk about any errors there, so I assume that means we literally need to call it again till it returns null.

That by itself seems reasonable as get_next_result() calls PQgetResult (which cannot return an error) and then PgResult::new() (which can return an error). So the only way get_next_result() would ever return an error is by hitting basically the current code block. We would like to ignore that as the first error message is relevant.

[weiznich]

Initially, I made changes to enclose that table definition, different from this, but it was cluttering the actual changes. I have reverted it to push only changes relevant to the ticket. Let me know your thoughts about it, whether we want to include such changes in current PR or in a separate one.

I would be fine with having these changes in this PR, as long as they are in a different commit

[heyrutvik]

Added separate commit to move table definition to its relevant test method. I haven't looked into all the tests file because of the time crunch but updated the same file where I added the test for the ticket. Also, updated the polling code as per your suggestion. Thanks, @weiznich.

[weiznich]

Thanks again for providing the example + working on the fix 👍 I will try to fix #3330 as well and then put all the recent fixes into a 2.0.1 patch release. I cannot give an ETA on the exact release date.