[BEAM-1082] Make the legacy SQL flag consistent between Java and Python

[sb2nov]

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

• Make sure the PR title is formatted like:
  [BEAM-<Jira issue #>] Description of pull request
• Make sure tests pass via mvn clean verify. (Even better, enable
  Travis-CI on your fork and ensure the whole test matrix passes).
• Replace <Jira issue #> in the title with the actual Jira issue
  number, if there is one.
• If this contribution is large, please file an Apache
  Individual Contributor License Agreement.

---

R: @chamikaramj @aaltay PTAL

[aaltay]

create a JIRA issue to fix the internals later. It would make sense to use use_standard_sql internally as well.

[sb2nov]

Done.

[aaltay]

capitalize True

[sb2nov]

Done.

[chamikaramj]

Please add the JIRA to the PR title - [BEAM-873]

[sb2nov]

Thanks for the comments.

R: @chamikaramj @aaltay PTAL

[chamikaramj]

LGTM

[sb2nov]

@robertwb please merge

[asfbot]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/beam_PreCommit_Java_MavenInstall/5495/
--none--

[asfbot]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/beam_PreCommit_Java_MavenInstall/5496/
--none--

[asfbot]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/beam_PreCommit_Java_MavenInstall/5497/
--none--

[dhalperi]

The name of the BigQuery option is use_legacy_sql with default true. Why should Beam's interface differ?

Actually, this is probably reasonable from a user interface pov. Never mind ;)

As long as the flags inside of the connector are named use_legacy_sql so that the logic can be clearly understood in forming the JSON objects sent to the BQ api, I'm fine here.

[sb2nov]

@dhalperi Thanks for raising this. There is a follow up PR on minimizing the use_legacy_sql flag within the sdk. Do you have thoughts on it ?

#1499

[aaltay]

@dhalperi Why is it reasonable from a user pov? Would not it make sense for external interfaces to match the underlying service (BQ)? (Either way the interface should be consistent across beam sdks)

[robertwb]

I actually agree with @aaltay . I think both Python and Java should follow whatever BigQuery calls this feature in its publicly facing docs/APIs.

[sb2nov]

I think we can do two things here:

1. Revert this and then change Java to use legacy_sql as a flag (https://cloud.google.com/bigquery/querying-data#bigquery-sync-query-java)
2. Just let beam diverge from bigquery api docs.

I think 1 would have been better from the start but now it is a backward incompatible :/

[robertwb]

Can we do 1 before the release? Right now we can change it, later we won't be able to.

…

On Dec 6, 2016 8:07 AM, "Sourabh Bajaj" ***@***.***> wrote: I think we can do two things here: 1. Revert this and then change Java to use legacy_sql as a flag ( https://cloud.google.com/bigquery/querying-data# bigquery-sync-query-java <https://cloud.google.com/bigquery/querying-data#bigquery-sync-query-java> ) 2. Just let beam diverge from bigquery api docs. I think 2 would have been better from the start but now it is a backward incompatible :/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1497 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdqgRZJ2enrr2hJ896jAZr-gCDfzYSeks5rFYeNgaJpZM4LDIvs> .

[sb2nov]

Would that still not be backward incompatible for java or is that okay ?