Identify a BigQuery dataset

A BigQuery dataset has an id field of the form projectId:datasetId and a datasetReference field:

"datasetReference": {
"datasetId": string,
"projectId": string
}

this suggests that a user should be able to init a DatasetId object as: DatasetId.of("projectId", "datasetId").

However, a ServiceOptions object is already tied to a specific project (and hence project id) so this makes me think that the user should not be allowed to access datasets for projects other than the one of the ServiceOptions object he is using. And also we should avoid asking a user to provide the project id every time he wants to instantiate a dataset object. This leads to something like DatasetId.of("projectId") and for every remote operation projectId is taken from ServiceOptions.
But I think this is undesirable as our API representation would make no distinction between datasets of different projects or cause weird situations like:

DatasetId remoteId = bigqueryService.get("someId").id(); // includes projectId
DatasetId localId = DatasetId.of("someId"); // does not include projectId
remoteId.equals(localId); // false

Thoughts?

A workaround I see is having a factory method in bigqueryService that takes a string datasetId and sets the projectId by fetching it from ServiceOptions.

This issue sounds similar to Datastore keys which also include a projectId as part of their path.
Though we allow a user to construct a key and explicitly setting a projectId the recommended way
wouldbe:

KeyFactory keyFactory = datastore.newKeyFactory();
Key key = keyFactory.newKey("name");

And as you suggested in that case the KeyFactory would be initialized with the projectId (and the default namespace).

BTW, does the bigquery api provide any functionality across projects?

AFAIK there are not functionalities across projects.

Do you think we should use a factory class? A would prefer a method for such simple operations.

No, I didn't think a factory-class is needed in this case. A datastore key is much more involved containing various parts (projectId, namespace, parent path, id or name) where in this case a factory method is sufficient.

Another option: I wonder if we really need to have a DatasetId class? What if user only supply datasetId as string (e.g. when constructing a request) where response will contain both datasetId and projectId (as separate fields)? Similar to what we do in BucketInfoand BlobInfo where some of the fields are read-only and populated only in response values.

Yes but a bucket name is already an identifier, isn't it? While a dataset name is an identifier only within its own project. It's a remote case but what if we serialize a local DatasetInfo (with no project id set) and deserialize it elsewhere where ServiceOptions.projectId is different from the original?

Indeed if one serialize a, lets say, a BigQueryDatasetthat was created by the user (and is therefore incomplete) than it will remain incomplete when it de-serialize it (projectId should return null in that case), however if one serialize a BigQueryDataset that was returned by the client, then that one would be be fully populated with a projectId.

Yes, not exactly like BlobInfo and BucketInfo, but similar with the concept of read-only fields (such as id, etag,..).

It was important for Datastore to provide a way for creating a key with any projectId, as there are
cases where one keeps (as values) cross project keys.

Yes but by doing this the same user-created BigQueryDataset might refer to two different datasets on the two serialization ends if they have different ServiceOptions.projectId.

Both deserialized instances should return null for projectId, but if they are passed as input to two different clients associated with 2 different project then they will create (and return in the response) a BigQueryDataset with 2 different projectId.

Is that the concern?

Yeah that's my concern, is this a desirable behavior? Considering that could be used also for deleting/updating a dataset. I feel like it's an unexpected behavior.

I feel that the use-case of one taking a serialized object (that is not a returned value by the service) from one project and using it in a different project in a way that yields unintentional results probably exists but is a weak one (low risk).

I can see a stronger use-case for doing it intentionally (e.g. creating similar datasets in different project).

However, if you feel that having something like a bigqueryService.newDatasetId(name) would be better than I think that is fine too.