throw an error instead of returning empty if client fails to deserialize query results

[qianyiwen2019]

Example:

define a struct MyRow with a field: decimal_col: Option
create a table with a column: decimal_col Nullable(Decimal(10, 4)))

when executing a query, deserialization should fail and client should throw an error to user.
but currently client just returns empty results.

    #[derive(Row, Serialize, Deserialize)]
    struct MyRow {
        pk: u32,
        decimal_col: Option<String>,
    }

    #[tokio::test]
    #[serial]
    async fn aaaaa() {
        let client = Client::default()
            .with_url("http://localhost:8123")
            .with_user("admin")
            .with_password("123456");

        // create table
        let create_table_sql = format!(
            "CREATE TABLE test_db_1.test(
        pk UInt32, 
        decimal_col Nullable(Decimal(10, 4)))
        PRIMARY KEY pk 
        ORDER BY pk"
        );

        client.query(&create_table_sql).execute().await.unwrap();

        // insert data
        client
            .query("INSERT INTO test_db_1.test VALUES(1, 1.1),(2, 2.2),(3, 3.3)")
            .execute()
            .await
            .unwrap();

        // query
        let rows = client
            .query("SELECT ?fields FROM test_db_1.test")
            .fetch_all::<MyRow>()
            .await
            .unwrap();

        println!("rows count: {}", rows.len());
        println!("rows: {}", json!(rows));
    }

output:
rows count: 0
rows: []

[loyd]

Nice catch, thank you.

The problem is that in the case of incorrect schema (here String instead of u64-based types), the length of String is expected to be significant (5496 bytes):

[src/cursor.rs:48:25] chunk.data = b"\x01\0\0\0\0\xf8*\0\0\0\0\0\0\x02\0\0\0\0\xf0U\0\0\0\0\0\0\x03\0\0\0\0\xe8\x80\0\0\0\0\0\0"
[src/rowbinary/de.rs:258:15] self.input.get_u8() = 0
[src/rowbinary/de.rs:130:9] size = 5496

However, the stream ends earlier, and the cursor doesn't check that the remaining unparsed bytes are left.

This bug was introduced in #169. Previously, the cursor checked this situation.

So, the valid error should be "NotEnoughData".

[qianyiwen2019]

@loyd thanks for your response and quick fix.
for the returning error, maybe it could provide more precise error messages indicating which field caused the failure, similar to how sqlx does.

[loyd]

maybe it could provide more precise error messages indicating which field caused the failure, similar to how sqlx does.

It's impossible to determine precisely the place of an error (in more complex cases than this one) without #10