I is possible to have it both ways with two different versions of the
filter function. One precise one:
filter(" name ", "op", "value") # the field name is taken as is
and one concise one:
filter("name op", "value") # the field name + op is parsed in a restricted
way

but there really should be a way to specify a filter on any supported
property name.

On Tue Dec 16 2014 at 8:13:10 PM Danny Hermes notifications@github.com
wrote:

I'm happy to support this but it seems like allowing developers to define
properties with any spaces is asking for undefined or unexpected
behavior. Adding leading and trailing spaces even more so.

ISTM there are two separate points / sides to take:

Just because the API supports it doesn't mean it's a best-practice.
An idiomatic library should encourage best-practices.

This implementation in gcloud-python is intended to be very
low-level and map the API exactly. Only power users will need it and higher
level ORMs such as ndb built on top of gcloud-python are intended for
typical users.

In my mind, the 2nd point is the more valid one, but we are not at all
being clear about this in our development. In addition we are spending time
making gcloud.datastore and it's modules idiomatic as if non-power users
would be interacting with it.

I strongly prefer a future that involves running ndb on top of
gcloud-python, but would like to have some sort of plan in place.

Luckily, if we do decide to implement this @Alfus
https://github.com/Alfus comments in #294
#294 carve out
a good chunk of what needs to be done.

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions