Datastore Query generates Bad Request with select+filter attached.

[chriseaton]

I have a pretty basic entity and am attempting to leverage a query to select it. But when I use the "select" function on the query (in conjunction with a "filter"), and then run the query, it generates a Bad Request error. Removing the "select" allows the query to run ok.

I can run either select or filter independently and they both work ok.

Failing query:

var qry = ds.createQuery('SocialMedia')
    .select(['id'])
    .filter('id =', items[0].id);
ds.runQuery(qry, function(err, entities) {
 ...

Creates Error:

{"errors":[],"code":400,"message":"Bad Request","response":{
"statusCode":400,"body":{"type":"Buffer","data": ...

Running

var qry = ds.createQuery('SocialMedia')
    .filter('id =', items[0].id);
ds.runQuery( ...

or

var qry = ds.createQuery('SocialMedia')
    .select(['id'])
ds.runQuery( ...

works fine and returns the results expected.

[stephenplusplus]

Thanks for reporting! @pcostell is this us or an issue of indexes?

[chriseaton]

Hi - some added information - and maybe this is why there is this issue... The "id" column that I'm trying to filter/select is not indexed. Does the gcloud lib support tagging fields as indexed?

[pcostell]

Yes, the id must be indexed, but it should be indexed by default. In fact
if you get results where you query for id = ... then it is indexed.
However, the issue you are hitting is that you can't project something
involved in an equality:

https://cloud.google.com/datastore/docs/concepts/projectionqueries#Datastore_Limitations_on_projections

Is there not more information in the returned error message? I think the
error that should be returned calls this out explicitly.

On Fri, Dec 11, 2015, 3:33 PM Christopher Eaton [email protected]
wrote:

Hi - some added information - and maybe this is why there is this issue...
The "id" column that I'm trying to filter/select is not indexed. Does
the gcloud lib support tagging fields as indexed?

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

[chriseaton]

Hi @pcostell,
Unfortunately there isn't a message like that, here's the err object in full minus my gc project id:

quick link to json parser

{"errors":[],"code":400,"message":"Bad Request","response":{"statusCode":400,"body":{"type":"Buffer","data":[67,97,110,110,111,116,32,117,115,101,32,112,114,111,106,101,99,116,105,111,110,32,111,110,32,97,32,112,114,111,112,101,114,116,121,32,119,105,116,104,32,97,110,32,101,113,117,97,108,105,116,121,32,102,105,108,116,101,114,46]},"headers":{"vary":"X-Origin, Origin,Accept-Encoding","content-type":"text/html; charset=UTF-8","date":"Fri, 11 Dec 2015 23:38:46 GMT","expires":"Fri, 11 Dec 2015 23:38:46 GMT","cache-control":"private, max-age=0","x-content-type-options":"nosniff","x-frame-options":"SAMEORIGIN","x-xss-protection":"1; mode=block","server":"GSE","alternate-protocol":"443:quic,p=0","alt-svc":"clear","accept-ranges":"none","connection":"close"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"www.googleapis.com","port":443,"hostname":"www.googleapis.com","hash":null,"search":null,"query":null,"pathname":"/datastore/v1beta2/datasets/xxxx/runQuery","path":"/datastore/v1beta2/datasets/xxxx/runQuery","href":"https://www.googleapis.com/datastore/v1beta2/datasets/xxxx/runQuery"},"method":"POST","headers":{"Content-Type":"application/x-protobuf","Authorization":"Bearer xxxx","User-Agent":"gcloud-node/0.24.1","content-length":68}}}}

[chriseaton]

However, the issue you are hitting is that you can't project something involved in an equality:

Thanks! That's it, if I change the op to something other than equality it works.

[pcostell]

Turns out the data of the response body is an ascii array which says:
"'Cannot use projection on a property with an equality filter.'"

@stephenplusplus - maybe the body should get parsed into a string?
@eddavisson - any idea why the JSON is getting sent like this?

[stephenplusplus]

I believe the body is being returned as a Buffer because that's just how the request library we're using does it. We wrap that raw response and return it in our custom ApiError type.

I played around with a 412 - Precondition Failed error. The response body is a buffer, but stringified (err.response.body.toString()) is something like no matching index found. When we return our custom ApiError to the user, we use the HTTP status message as the "message" to associate with the error. When you console.log or throw an error, the message is what's displayed. Maybe we should use that in combination with the parsed response.body, if it exists?

In this case, it would look like:

console.log(err);
// Precondition Failed - no matching index found.

// @callmehiphop