Skip to content

bigquery: don't return null schema#2510

Merged
pongad merged 1 commit intogoogleapis:masterfrom
pongad:bq-null
Oct 23, 2017
Merged

bigquery: don't return null schema#2510
pongad merged 1 commit intogoogleapis:masterfrom
pongad:bq-null

Conversation

@pongad
Copy link
Copy Markdown
Contributor

@pongad pongad commented Oct 12, 2017

Fixes #2477

@pongad pongad requested a review from tswast October 12, 2017 00:23
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Oct 12, 2017

// Don't compare strings directly; BigQuery might reorder.
String gotCsvContent = new String(storage.readAllBytes(BUCKET, EXTRACT_FILE), StandardCharsets.UTF_8);
Truth.assertThat(gotCsvContent.split("\n")).asList().containsExactly(CSV_CONTENT.split("\n"));

This comment was marked as spam.

This comment was marked as spam.

Table toPb() {
Table tablePb = new Table();
if (schema != null) {
if (schema.getFields().size() != 0) {

This comment was marked as spam.

This comment was marked as spam.

Copy link
Copy Markdown
Contributor

@garrettjonesgoogle garrettjonesgoogle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Copy Markdown
Contributor

@vam-google vam-google left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for being late on this and blocking merge in an a semi-rude way, but most probably the correct way to solve this is to remove checkNotNull(schema) from com.google.cloud.bigquery.TableDefinition.Builder.setSchema(). (i.e. fix it form the "other end").

The arguments to support this:

  1. There are other places where schema can be null (check FieldValueList.get(String) method for example).

  2. In general builders usually accept nulls and do not enforce that kind of validation (check other builders). Builders should allow any intermediate state of things, since any state of builder is not final and it can be "fixed" before actual build() is called.

  3. (This is the most important one) if a table does not have a schema and it is not returned from the server, we should be explicit about it (i.e. no schema - here is your null). Faking schema, when server returns null introduces inconsistency between server state and client and can cause weird bugs / confusing behavior in the future.

Table toPb() {
Table tablePb = new Table();
if (schema != null) {
if (schema.getFields().size() != 0) {

This comment was marked as spam.

This comment was marked as spam.

@pongad
Copy link
Copy Markdown
Contributor Author

pongad commented Oct 18, 2017

@vam-google For (2), AutoValue also rejects setFoo(null) so there's so precedent here. The rest of your points are valid though; I don't think I understand BigQuery enough to know what the right answer is. @tswast Do you have an opinion?

@tswast
Copy link
Copy Markdown
Contributor

tswast commented Oct 18, 2017

(3) You're right that allowing nulls is the most correct way to fix this.

The BigQuery API represents a schema as an object (with just one property: fields). This means that there is a difference between a null schema and an empty schema, though I don't know of a case where an empty schema would be returned by the API. I suppose there could be a case in the future where it makes a difference (such as if another property besides fields was added to schema)

@pongad
Copy link
Copy Markdown
Contributor Author

pongad commented Oct 18, 2017

@tswast From this issue it looks like BigQuery returns null schema if a table is created with no fields. If we allow null in client lib, is this something we can fix on the server side?

@tswast
Copy link
Copy Markdown
Contributor

tswast commented Oct 18, 2017

What would we fix server-side? It's a problem with the way the API is designed so making schema non-nullable server-side would be a breaking change.

@pongad
Copy link
Copy Markdown
Contributor Author

pongad commented Oct 19, 2017

@tswast Ah yes, sorry. I was being stupid. Shall we fix this by allowing user to set Schema to null then?

@tswast
Copy link
Copy Markdown
Contributor

tswast commented Oct 19, 2017

Yeah, allowing null is the safest thing to do in regards to avoiding problems in the future due to a difference in how schemas are handled in the client versus the API.

It does feel a bit yucky as a user, but better to err on the side of avoiding a disconnect between API representation and client library.

Schema can be set to null in a response we get from server.
However, we do not allow the user to set to null,
causing confusion.

This commit fixes this by allowing user to set null schema.

Fixes #2477.
@pongad
Copy link
Copy Markdown
Contributor Author

pongad commented Oct 20, 2017

Thank you @tswast sounds good. I updated the PR. PTAL

@tswast
Copy link
Copy Markdown
Contributor

tswast commented Oct 20, 2017

LGTM.

@pongad pongad merged commit 72ae1ff into googleapis:master Oct 23, 2017
@pongad pongad deleted the bq-null branch October 23, 2017 03:48
schmidt-sebastian pushed a commit to FirebasePrivate/google-cloud-java that referenced this pull request Nov 9, 2017
Schema can be set to null in a response we get from server.
However, we do not allow the user to set to null,
causing confusion.

This commit fixes this by allowing user to set null schema.

Fixes googleapis#2477.
chingor13 pushed a commit that referenced this pull request Feb 20, 2026
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes This human has signed the Contributor License Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants