Dataset ID aliases don't behave consistently.

[dhermes]

Using the "human-readable" version foo of the prefixed ID s~foo (or e~foo) is allowed in a URI but not in a request payload (and will never be returned in a response since foo gets mapped to s~foo in the response).

This inconsistency can catch user's off-guard and requires custom behavior in to_protobuf()-type methods which essentially always ignore the dataset_id on a PartitionId message and only use the dataset ID in the URI.

/cc @silvolu @tseaver

---

Some examples

1. Sending a query to

https://www.googleapis.com/datastore/v1beta2/datasets/foo/runQuery

which has RunQueryRequest.partition_id.dataset_id == 'foo' in the payload results in

app s~foo cannot access app foo's data

2. Sending a mutation (or a lookup) to one of

https://www.googleapis.com/datastore/v1beta2/datasets/foo/allocateIds
https://www.googleapis.com/datastore/v1beta2/datasets/foo/commit
https://www.googleapis.com/datastore/v1beta2/datasets/foo/lookup

which has Key.partition_id.dataset_id == 'foo' (either directly in a key
or in an Entity) in the payload results in

app s~foo cannot access app foo's data

3. Sending a filtered or ancestor query which does not have
   RunQueryRequest.partition_id.dataset_id set in the payload but does have
   the dataset ID set in either the ancestor key

The query app is 'foo' but ancestor.key app is 'foo'.

or in the __key__ filter

__key__ filter app is foo but query app is s~foo

[eddavisson]

Thanks for the report -- we are planning on fixing this in a future version of the API.

In the mean time, leaving PartitionId.dataset_id blank input should do the right thing in both mutations and query filters.

[dhermes]

@eddavisson @pcostell Do you have an idea of when this might land?

[dhermes]

@pcostell will this be addressed in v1beta3?

[eddavisson]

Yes.

[dhermes]

w00t!

[pcostell]

Per https://cloud.google.com/datastore/release-notes, in v1beta3 it is always project_id and never includes the prefix ("s~" and friends).