DISCUSSION: Should dataset ID be set on datastore key?

[dhermes]

This question came up in the review in #282 while trying to define the "correct" behavior of datastore.Key.__eq__.

The only remaining use of Key._dataset_id is in to_protobuf but #121 seems to indicate that the dataset ID is not needed on a Key.

ISTM we should just remove _dataset_id from the Key class, even though it is returned in the protobuf after an entity is stored/retrieved. @pcostell WDYT?

[pcostell]

One issue is that keys may point to other datasets so you can loose that information. So you may want to leave the dataset in there with whatever is populated from the server. I know this complicates equality checks, we plan to fix this in a future version of the API by having a more consistent dataset naming policy.

[dhermes]

I can't imagine a situation where someone would have a Key object with a dataset ID and have no other way of determining the dataset.

Are there typical cases where one codebase would even interact with multiple datasets at once? (I suppose a developer service could do this, e.g. an analytics tool, but I'd expect such an application to keep datasets carefully distinguished.)

[pcostell]

There are very few who currently do so in App Engine, but my guess too is
the analytics sort of app.

I guess I was thinking of something where the analytic app stores in its
datastore an Entity with a key property for one of its customers datasets.
When it gets that entity, it will have a Key property with a dataset that
is different than the dataset that it is stored in. If you drop the
dataset_id completely, the analytic app would not know which dataset the
key corresponded to.

Of course you could just mark it as a know limitation until a future
datastore API version fixes this. If a developer wants to do this now they
can store the external dataset as a separate string property.

On Fri Oct 24 2014 at 3:29:31 PM Danny Hermes notifications@github.com
wrote:

I can't imagine a situation where someone would have a Key object with a
dataset ID and have no other way of determining the dataset.

Are there typical cases where one codebase would even interact with
multiple datasets at once? (I suppose a developer service could do this,
e.g. an analytics tool, but I'd expect such an application to keep datasets
carefully distinguished.)

—
Reply to this email directly or view it on GitHub
#293 (comment)
.

[dhermes]

Indeed. And I'd imagine the service would be doing reads only.

How does this sound as a resolution of this issue / discussion?
We make it very clear in the docstring when and how the _dataset_id will be set on a Key.

[jgeewax]

Sounds like we will keep the dataset_id property on a Key?

Can you be more specific with an example of what this decision looks like? I'm just having trouble wrapping my head around the solution proposed...

[dhermes]

@jgeewax the solution is to leave the code as-is, just do a better job setting the expectation for the code's behavior.