Skip to content

Conversation

@gjuggler
Copy link

@gjuggler gjuggler commented Nov 6, 2022

See associated ticket for a full description of the issue.

tl;dr it will be more consistent for our CLI to resolve BQ datasets and tables using the format:

[project_id]:[dataset_id].[opt_table_id]

This is the format expected by the bq command-line, and should be Terra's default output.

At the same time, for anyone who wants to include a Terra reference within BigQuery SQL, they should use the format we used to output, e.g.

[project_id].[dataset_id].[opt_table_id]

This PR switches the default behavior and adds a new --bq-path option to specify the SQL-compatible output format.

We should notify our Solutions team before this change goes live, as it will change the default BQ resource resolution.

(Note that this PR is intentionally making a breaking change in a core command. This should be frowned upon as a general matter of course! However, I am high confidence that the existing behavior is incorrect to the point of being actively misleading, and as a result the existing resolve command is not likely relied-upon by our small existing user base. The benefit to adjusting sooner than later outweighs the cost of breaking backwards compatibility.)

@gjuggler gjuggler changed the title Switch default behavior and add a FULL_PATH_SQL option. [PF-2195] Switch default BQ resolve syntax and add a FULL_PATH_SQL option. Nov 7, 2022
@gjuggler gjuggler changed the title [PF-2195] Switch default BQ resolve syntax and add a FULL_PATH_SQL option. [PF-2195] Switch default BQ resolve delimiter and add a FULL_PATH_SQL option. Nov 7, 2022
@gjuggler gjuggler marked this pull request as ready for review November 7, 2022 13:54
@gjuggler gjuggler requested a review from melissachang November 8, 2022 20:10
Copy link
Contributor

@melissachang melissachang left a comment

Choose a reason for hiding this comment

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

I'm not sure which should be default. It could be that a user rarely runs bq, and often runs SQL queries (eg in a notebook) against data collection BQ resources. If you want, I'm happy to shoot an email to solutions. The email could kill 2 birds with 1 stone: ask for their preference, and possibly notify them of breaking change.

If we keep bq as default, I can update UI to match. (In the future, this logic should be in FrontendServer.)

/** This enum specifies the possible ways to resolve a BigQuery resource. */
public enum BqResolvedOptions {
FULL_PATH, // For data table: [project id].[dataset id].[data table id if applicable]
FULL_PATH, // For data table: [project id]:[dataset id].[data table id if applicable]
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggest FULL_PATH -> FULL_PATH_BQ and some comment changes

// project:dataset.table, used for bq CLI
FULL_PATH_BQ,
// project.dataset.table, used for SQL
FULL_PATH_SQL,

(I left out if applicable for brevity..)


/** Gets cloud identifier for Dataset in full-path: [project id].[dataset id] */
/** Gets cloud identifier for Dataset in full-path: [project id]:[dataset id] */
public static String getDatasetFullPath(String projectId, String datasetId) {
Copy link
Contributor

Choose a reason for hiding this comment

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

getDatasetFullPathBq ?

@gjuggler
Copy link
Author

gjuggler commented Nov 9, 2022

I'm not sure which should be default. It could be that a user rarely runs bq, and often runs SQL queries (eg in a notebook) against data collection BQ resources. If you want, I'm happy to shoot an email to solutions. The email could kill 2 birds with 1 stone: ask for their preference, and possibly notify them of breaking change.

If we keep bq as default, I can update UI to match. (In the future, this logic should be in FrontendServer.)

👍 I emailed the solutions team, and will come back to this PR once we have a clearer signal on which default to prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants