Consider adding helper `ResultSetMetadata -> ColumnarBuffer<AnyColumnBuffer>`?

[jorgecarleitao]

for users that do not need custom buffers, it could make sense to offer the following helper:

pub fn buffer_from_result_set(
    resut_set_metadata: &impl ResultSetMetadata,
    max_batch_size: usize,
) -> Result<ColumnarBuffer<AnyColumnBuffer>> {
    let num_cols: u16 = resut_set_metadata.num_result_cols()? as u16;

    let descs = (0..num_cols).map(|index| {
        let mut column_description = ColumnDescription::default();

        resut_set_metadata
            .describe_col(index + 1, &mut column_description)?;

        Ok(BufferDescription {
            nullable: column_description.could_be_nullable(),
            kind: BufferKind::from_data_type(column_description.data_type)?,
        })
    });

    Ok(buffer_from_description(max_batch_size, descs))
}

to be used with prepared statements as follows:

let max_batch_size = 100;

let query = format!("SELECT a FROM {table_name} ORDER BY id");
let mut prepared = connection.prepare(&query)?;

let buffer = buffer_from_result_set(&prepated, max_batch_size);

let cursor = prepared.execute(()).unwrap().unwrap();
let mut cursor = cursor.bind_buffer(buffer)?;

[pacman82]

Hello @jorgecarleitao ,

thanks for your suggestion. Before going into design, I did have the same thought in the past. My thought back then had been, that I do not want to make it to persuasive, to base the application buffers on the datasource schemas, but rather push user in the direction of thinking what they want to do with the data, and choose the buffers based on that.

This is at least true for the level of abstraction which ODBC provides. One of my motivations for creating arrow-odbc was exactly that users who just want to story data from a source with no a priori schema knowledge would have a goto library to do that.

Cheers, Markus

[baoyachi]

It's seems AnyColumnBuffer rename to AnyBuffer with new commit

[pacman82]

There is that, but currently I feel picking sensible defaults, requires more knowledge about what the user is trying to accomplish. It's by far not as straight forward as it may seem. It depends just as much (and sometimes more) on what you plan to do with the data, as it dependens on the Relational data type it is associated with.

I currently feel odbc-api is to unbiased about the usecase to pick sensible defaults.

I'll close this issue, at least for now.