-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat(spanner): allow untyped nil values in parameterized queries #4482
Conversation
Removes the restriction that nil valued parameters must be typed. The current restriction prevents the usage of DML statements with one or more untyped nil parameter values to be used to insert/update a value to NULL. Cloud Spanner does not require all parameters to be typed, only when it would otherwise be ambigous what type should be used (e.g. non-NULL STRING/BYTES values). This restriction also prevents the usage of the go/sql driver with gorm, as gorm will generate statements with untyped nil parameter values. Fixes #4481
Skip testing DML with untyped parameters on the emulator as it does not support untyped parameters. See GoogleCloudPlatform/cloud-spanner-emulator#31
spanner/integration_test.go
Outdated
// Write rows into table first using DML. Only do this on real Spanner | ||
// as the emulator does not support untyped parameters. | ||
// TODO: Remove when the emulator supports untyped parameters. | ||
if isEmulatorEnvSet() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be !isEmulatorEnvSet()
if the emulator env is not set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep 👍
{ | ||
nil, | ||
nullProto(), | ||
nil, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious: would this work? Because it expects a *sppb.Type but we give nothing, e.g.,
func numericType() *sppb.Type {
return &sppb.Type{Code: sppb.TypeCode_NUMERIC}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this test it would fail, as the test will verify that the param type is not set (or set to nil). That comparison will fail if we set it to TypeCode_NUMERIC
. If we were to do something like that on production, it will also fail. I tried it out with the integration test, and it will refuse to insert a NULL
value with type NUMERIC
into a STRING
column:
failed to insert values using DML: spanner: code = "InvalidArgument", desc = "Value has type NUMERIC which cannot be inserted into column String, which has type STRING [at 1:50]\\nINSERT INTO Types (RowId, `String`) VALUES (@id, @value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Removes the restriction that nil valued parameters must be typed. The current restriction prevents the usage of DML statements with one or more untyped nil parameter values to be used to insert/update a value to NULL. Cloud Spanner does not require all parameters to be typed, only when it would otherwise be ambiguous what type should be used (e.g. non-NULL STRING/BYTES values).
This restriction also prevents the usage of the go/sql driver with gorm, as gorm will generate statements with untyped nil parameter values.
Fixes #4481