-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with Mutable Borrow of Statement when Accessing Column Names (Option::unwrap()) #251
Comments
I ran into this exact issue. There's a catch-22 if you don't know the number of columns in advance. You can't get the column count without executing the query, and you can't execute the query without knowing the column count (because you don't know which columns to get). |
@ravi-nallappan @Timmmm The trick is to call |
That worked for me too. This is an issue with the duckdb api because doing the same in rusqlite works fine: let mut stmt = conn.prepare("SELECT id, name, data FROM person")?;
let cols: Vec<String> = stmt.column_names().iter().map(|&s| s.to_string()).collect();
println!("cols: {:?}", cols);
let mut rows = stmt.query([])?; |
I did a deep dive into this while working on #333 as I ran into a similar issue. The main problem is that all functions that depend on |
FWIW you can access the rows later in the row iterator: let mut rows = stmt.query([]).unwrap();
while let Some(row) = rows.next().unwrap() {
let cols = row.as_ref().column_names();
// ... |
Hi team, is there update on this issue? I checked the latest codes on main branch, it will still fail when I try to get any schema related information before I execute the statement. and I just can't execute the stmt first because of the immutable and mutable references on the stmt exist in the same block |
I encountered a problem similar to a previously closed issue (#204). However, in my use case, I need to execute arbitrary select-SQL and generate a vector of maps, where each map represents a row with column name/value pairs.
Code Snippet:
Problem Description:
The issue arises because the statement is mutably borrowed during the time when column names need to be accessed.
Environment:
{ version = "0.9.2", features = ["json"] }
Could you suggest a workaround for this issue? Additionally, is this behavior intentional for reasons I might not be aware of?
Thank you for your assistance and for maintaining this project.
The text was updated successfully, but these errors were encountered: