Filters should support properties with leading/trailing whitespaces in the name.

[silvolu]

.filter('property with space =', 1) or .filter(' property with leading and trailing spaces =', 1) should result in the properties names not losing the trailing/leading whitespaces.
More context in #294 (comment)

[dhermes]

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 comments in #294 carve out a good chunk of what needs to be done.

[Alfus]

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)
.

[tseaver]

I really don't understand the use case for the two-argument form:

derived = base.filter('prop name =', 'value)

versus the more natural / idomatic three-argument spelling:

derived = base.filter('prop name', '=', 'value)

As a bonus, the three-argument form makes the problem with leading / trailing (even embedded) spaces go away.

[silvolu]

I'm for the three-argument form as well. @jgeewax? #294 (comment)

[dhermes]

FYI to all. I am working on this right now and changing the signature to

def filter(self, property_name, operation, value):

so that now

filtered_query = query.filter('age', '>', 50)

will be the way to call filter.

This makes it much simpler to support property names with any arbitrary kind of whitespace and also is a true mapping to the underlying proto (I mentioned this before). In light of my comment above, being a truer mapping is a good thing.

Please chime in if there are any issues or concerns.