-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Use attachValues in SQL #11259
Use attachValues in SQL #11259
Conversation
run sql postcommit |
I've changed the description from |
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.
Before this change the validation in addValue
would ensure output types were correct, so I'm not sure that our tests explicitly check for that failure case. Can you verify the tests still catch regressions where incorrect types are produced by SQL?
LGTM
Actually it looks like this completely broke BeamCalcRel. You should fix that too. |
run sql postcommit |
FYI, I was going through our internal test failures and found a bunch that will probably be much more difficult to debug after this change. I included a sample of the current failures below, it would be nice to have a way to turn
|
@apilloud I added a pipeline option that can be used to enable more verbose Row checking. Dataflow can enable this on its internal tests. |
LGTM |
Run SQL PostCommit |
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.
It's concerning that none of the checks caught this error. Is SQL PreCommit not building this code? Hopefully SQL PostCommit catches it
Row row = | ||
verifyRowValues | ||
? Row.withSchema(outputSchema).addValues(fieldValues).build() | ||
: Row.withSchema(outputSchema).attachValues(fieldValues); |
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.
I think this is missing a .build()
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.
pr/10883 changed attachValues() to return a Row, so build() not needed.
Row outputRow = | ||
verifyRowValues | ||
? Row.withSchema(outputSchema).addValues(values).build() | ||
: Row.withSchema(outputSchema).attachValues(values); |
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.
and here
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.
ditto
Row row = | ||
verifyValues | ||
? Row.withSchema(schema).addValues(objects).build() | ||
: Row.withSchema(schema).attachValues(objects); |
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.
and here
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.
ditto
PostCommit doesn't get it either.. |
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.
Ah nevermind, the tests are right and I am wrong. This API changed in #10883
Use the more efficient attachValues when building rows in SQL. addValues does a deep copy of the parameter, while addValue does not. We have also recently made API improvements that makes addValues slightly less efficient, so this allows SQL to bypass that.
We are not using attachValues on any of the IOs. This is strictly for internal rows generated by SQL.