You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am reading a sqlite table into a dataframe, where one column is
r real
and all values are missing. I use
df=DBInterface.execute(db, sql) |> DataFrame;
and get df.r to be of type missing (think it should be Union{Missing,Float64} )
SQLite.jl returns the correct type, but it does not make it when converted to a dataframe.
not sure if this is a bug, but thought I would let you all know
This is the default definition because in sqlite, declared column types are just "suggestions" instead of any kind of real constraint. Indeed, you can declare a column type to be DOUBLE, but then insert as many strings as you want and it won't complain. Hence we ran into too many issues where this "flexibility" caused issues when trying to query data from a table.
I think we should bring back the stricttypes::Bool=false keyword argument though, so you could do DBInterface.execute(db, sql; stricttypes=true) and it would produce a Tables.Schema that returns the declared column types.
This is supported through the strict result option added in #304, included in v1.6.0. I verified registered SQLite.jl 1.9.0 on Julia 1.9.4 and 1.13.1: an all-NULL REAL column becomes Union{Missing,Float64} when using the prepared-statement form:
The explicit () is the parameter collection. It lets strict=true reach SQLite's result option; the connection/SQL keyword convenience form treats keywords as bound query parameters instead. Default result reading still infers types from values to handle SQLite's flexible column typing.
Both runtimes pass seven checks for row counts, all-missing values, strict column types, and an empty result's declared type. Closing this as implemented without changing the default behavior.
AI disclosure: This work was prepared with assistance from OpenAI Codex.
Activity
nalimilan commentedon Nov 28, 2021
This is probably due to:
SQLite.jl/src/tables.jl
Line 33 in f9c7d62
@quinnj What's the reason for using the actual content types instead of the ones declared in the SQL table?
quinnj commentedon Dec 2, 2021
This is the default definition because in sqlite, declared column types are just "suggestions" instead of any kind of real constraint. Indeed, you can declare a column type to be DOUBLE, but then insert as many strings as you want and it won't complain. Hence we ran into too many issues where this "flexibility" caused issues when trying to query data from a table.
I think we should bring back the
stricttypes::Bool=falsekeyword argument though, so you could doDBInterface.execute(db, sql; stricttypes=true)and it would produce aTables.Schemathat returns the declared column types.quinnj commentedon Oct 4, 2026
This is supported through the strict result option added in #304, included in v1.6.0. I verified registered SQLite.jl 1.9.0 on Julia 1.9.4 and 1.13.1: an all-NULL
REALcolumn becomesUnion{Missing,Float64}when using the prepared-statement form:The explicit
()is the parameter collection. It letsstrict=truereach SQLite's result option; the connection/SQL keyword convenience form treats keywords as bound query parameters instead. Default result reading still infers types from values to handle SQLite's flexible column typing.Both runtimes pass seven checks for row counts, all-missing values, strict column types, and an empty result's declared type. Closing this as implemented without changing the default behavior.
AI disclosure: This work was prepared with assistance from OpenAI Codex.