Allow sqldeserialize to return non-T to allow value/schema mismatch #267
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #244. Last time we refactored SQLite.Query, we took out any strict
schema enforcement, mainly by defining the
Tales.schema
ofSQLite.Query
to benothing
, thus allowing sinks to "discover" theschema dynamically, which better fits the sqlite data type model. As
reported in #244, however, we missed a case where we pass in the
declared column's type to
sqlitevalue
and thensqldeserialize
wasbeing forced to assert that what it deserialized was a value of that
type. That isn't generally possible, since the declared sqlite types are
such a small subset of what we'll technically serialize/deserialize with
custom Julia values. By removing the type assertion, we allow
sqldeserialize to do its job and sqlitevalue to return whatever gets
deserialized.