-
Notifications
You must be signed in to change notification settings - Fork 601
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
spanner: Unable to insert multiple rows in a single table.insert/transaction.insert call when some rows lack a value for nullable columns #2411
Labels
api: spanner
Issues related to the Spanner API.
priority: p0
Highest priority. Critical issue. P0 implies highest priority.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Comments
jscinoz
changed the title
spanner: Incorrect handling of rows with missing nullable values in insert()
spanner: Unable to insert multiple rows at once when some rows lack a value for nullable columns
Jun 27, 2017
jscinoz
changed the title
spanner: Unable to insert multiple rows at once when some rows lack a value for nullable columns
spanner: Unable to insert multiple rows in a single table.insert/transaction.insert call when some rows lack a value for nullable columns
Jun 27, 2017
stephenplusplus
added
api: spanner
Issues related to the Spanner API.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
labels
Jun 27, 2017
Thanks for reporting, @jscinoz! Would you be willing to send a PR? |
Sure thing, I will implement the fix as described above and send through a PR today. |
jscinoz
added a commit
to AvokaTech/google-cloud-node
that referenced
this issue
Jun 28, 2017
Prior to this change, attempting to insert multiple rows at once with Table#insert or Transaction#insert where some rows lack a value for nullable columns would result in data attempting to be inserted into the incorrect column, due to a flawed assumption in transaction-request.js that every single row contains exact same set of columns, and that the order of keys returned by Object.keys would be identical for each and every row. This fixes googleapis#2411.
jscinoz
added a commit
to AvokaTech/google-cloud-node
that referenced
this issue
Jun 28, 2017
Prior to this change, attempting to insert multiple rows at once with Table#insert or Transaction#insert where some rows lack a value for nullable columns would result in data attempting to be inserted into the incorrect column, due to a flawed assumption in transaction-request.js that every single row contains exact same set of columns, and that the order of keys returned by Object.keys would be identical for each and every row. This fixes googleapis#2411.
PR created: #2417 |
vkedia
added
the
priority: p0
Highest priority. Critical issue. P0 implies highest priority.
label
Jun 30, 2017
I'm working on it now. |
Thanks! |
stephenplusplus
pushed a commit
to stephenplusplus/gcloud-node
that referenced
this issue
Jun 30, 2017
Prior to this change, attempting to insert multiple rows at once with Table#insert or Transaction#insert where some rows lack a value for nullable columns would result in data attempting to be inserted into the incorrect column, due to a flawed assumption in transaction-request.js that every single row contains exact same set of columns, and that the order of keys returned by Object.keys would be identical for each and every row. This fixes googleapis#2411.
New PR in #2426. |
stephenplusplus
added a commit
that referenced
this issue
Jul 5, 2017
…ns (#2426) * spanner: Properly handle multi-row mutations with heterogeneous columns Prior to this change, attempting to insert multiple rows at once with Table#insert or Transaction#insert where some rows lack a value for nullable columns would result in data attempting to be inserted into the incorrect column, due to a flawed assumption in transaction-request.js that every single row contains exact same set of columns, and that the order of keys returned by Object.keys would be identical for each and every row. This fixes #2411.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
api: spanner
Issues related to the Spanner API.
priority: p0
Highest priority. Critical issue. P0 implies highest priority.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
In transaction-request.js, there is the following (L687-695):
There are at least two bugs here:
When an array is provided to table.insert(), if some objects do not have a given key (which is perfectly valid if the column said key corresponds to is nullable), the array within
values
for this object will not be the same length as the columns array, and indices incolumns
will no longer correspond to the correct value in thevalues
array for this row/object. This results in (best case) misleading error messages from Spanner about incorrect data types. Worse still, if it so happens that the value in thevalues
array for this row and incorrect column index is the same type as the value for the correct column index, the insert request will succeed, and end up storing data in the wrong column entirely.If a consumer of this library works around the issue above by populating missing nullable keys with
null
, as the code above relies on the order of values returned by Object.keys, the newly added values will be at the end of the array returned by Object.keys (which returns keys in insertion order), and again, the indices between thecolumns
array, and thevalues
array for affected rows will no longer align, with the same end result as what occurs with issue 1 above.This could be fixed by iterating over all rows (rather than naively assuming all rows have identical keys to the first row) and collecting all unique keys into a single array which is subsequently sorted lexically, to build the value for
columns
. Likewise, the value forvalues
would be constructed by mapping overcolumns
(rather thanObject.keys(keyVal)
) and pulling out the corresponding value fromkeyVal
to pass tocodec.encode
.The text was updated successfully, but these errors were encountered: