René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Identify a BigQuery dataset","articleBody":"A [BigQuery dataset](https://cloud.google.com/bigquery/docs/reference/v2/datasets?hl=en) has an `id` field of the form `projectId:datasetId` and a `datasetReference` field:\n\n\u003e \"datasetReference\": {\n\u003e     \"datasetId\": string,\n\u003e     \"projectId\": string\n\u003e   }\n\nthis suggests that a user should be able to init a `DatasetId` object as: `DatasetId.of(\"projectId\", \"datasetId\")`. \n\nHowever, 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`.\nBut I think this is undesirable as our API representation would make no distinction between datasets of different projects or cause weird situations like:\n\n``` java\nDatasetId remoteId = bigqueryService.get(\"someId\").id(); // includes projectId\nDatasetId localId = DatasetId.of(\"someId\"); // does not include projectId\nremoteId.equals(localId); // false\n```\n\nThoughts?\n\nA workaround I see is having a factory method in `bigqueryService` that takes a string `datasetId` and sets the `projectId` by fetching it from `ServiceOptions`.\n","author":{"url":"https://github.com/mziccard","@type":"Person","name":"mziccard"},"datePublished":"2015-10-29T19:30:26.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/310/google-cloud-java/issues/310"}