Change in TableId behaviour for non default BigQueryClient project 1.44 -> 1.45

[NickApostolidesMatillion]

When using the getTable method of the BigQuery client the project of the TableId is overwritten. TableId would previously ignore this if a project had been set. Table Id has been changed such that the project is always overwritten. There is now no way to get a table for a project other than the one the client was created for.

TableId tableId = TableId.of(project, schema, tableName);
Table table = client.getTable(tableId);
// table returns null if project != client.getOptions().getProjectId()

this is due to the change in TableId

In BigQueryImpl:

public Table getTable(TableId tableId, TableOption... options) {
    final TableId completeTableId = tableId.setProjectId(getOptions().getProjectId());
    ...

TableId old code:

TableId setProjectId(String projectId) {
  return getProject() != null ? this : TableId.of(projectId, getDataset(), getTable());
}

TableId new code:

TableId setProjectId(String projectId) {
  Preconditions
    .checkArgument(!Strings.isNullOrEmpty(projectId), "Provided projectId is null or empty");
  return TableId.of(projectId, getDataset(), getTable());
}

[MMMarcy]

@NickApostolidesMatillion I'm the author of that change. It was due to #3283 and this behavior is definitely unintended. However, reverting the change will re-open the mentioned issue.

Perhaps something like:

public Table getTable(TableId tableId, TableOption... options) {

    final TableId completeTableId = tableId.setProjectId(
        tableId.getProjectId() == null
        ? getOptions().getProjectId()
        : tableId.getProjectId()
    );
...
}

Would solve your issue and still keep the fix for #3283 (granted that now you supply a TableId with the desired projectId already set).

[NickApostolidesMatillion]

@MMMarcy that would work for us. It is more suitable to have this logic in BigQueryImpl.

Thanks

[MMMarcy]

Perfect. Waiting for the owners thoughts now. If positive, I can open a PR

[MMMarcy]

Actually, thinking more about this using the proposed solution I mentioned hides too much of the behavior to the caller. Maybe overloading the getTable method with

public Table getTable(TableId tableId, ProjectId projectId, TableOption... options) {
...
}

seems a better alternative.

[NickApostolidesMatillion]

TableId already has a factory method including the project:

public static TableId of(String project, String dataset, String table)

I would suggest that if the project is set in TableId, the developer knows the project he/she wants.