Skip to content

feat: cover null-typed bind parameter columns#257

Open
fornwall wants to merge 2 commits into
adbc-drivers:mainfrom
fornwall:test/bind-null-typed
Open

feat: cover null-typed bind parameter columns#257
fornwall wants to merge 2 commits into
adbc-drivers:mainfrom
fornwall:test/bind-null-typed

Conversation

@fornwall

@fornwall fornwall commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Add a test that binds a batch whose parameter column has the Arrow type null.

Verified that existing drivers for sqlite, postgres, mysql, duckdb and flightsql passes.

Context: Had a bug/confusion around this myself when implementing a new driver, so this test would have helped.

Adds a test that binds a batch whose parameter column has Arrow type
null and asserts NULL is bound per row.

Signed-off-by: Fredrik Fornwall <fredrik@fornwall.net>
@fornwall
fornwall requested a review from lidavidm as a code owner July 14, 2026 09:51
@fornwall fornwall changed the title test(statement): cover null-typed bind parameter columns feat: cover null-typed bind parameter columns Jul 14, 2026
Comment on lines +140 to +143
cursor.adbc_statement.set_sql_query(
f"INSERT INTO {sample_table} ({id_}, {value}) "
f"VALUES ({driver.bind_parameter(1)}, {driver.bind_parameter(2)})"
)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these queries be overridable?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that queries should be overridable when there is a need (an upfront knowledge if the sql is not portable, or if a driver has found a need to override it), and not every query needs to be overridable.

Not every existing query is overridable.

But let me know if you think every new query should be overridable (or at least if this new one should), and I'll add it here!

result = pyarrow.RecordBatchReader._import_from_c(handle.address).read_all()
assert result[0].to_pylist() == [2, 3, 4, 5]

@pytest.mark.requires_features(["statement_bind"])

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also uses prepare, albeit bind probably implies prepare already

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, no drawback with being explicit? Added a dependency on statement_prepare: 70de981

value = driver.quote_identifier("value")
parameters = pyarrow.RecordBatch.from_pydict(
{
"0": pyarrow.array([7001], type=pyarrow.int64()),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this column anyways?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reused the sample_table test fixture (defined here), instead of creating a new one. I think that makes sense, but let me know if you think otherwise!

@fornwall
fornwall requested a review from lidavidm July 15, 2026 07:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants