Missing GQL support

[tseaver]

The protobuf spec for queries suggests that queries should support GQL, but that support is missing. Do we need to add support?

[dhermes]

ISTM that GQL is an artifact of days gone by, i.e. what people thought was useful when the datastore was initially created. Having it in the proto just allows continued support of existing apps which use GQL.

For me, explicitly not supporting GQL is a good thing, but I'm happy to support it if people think we should.

[silvolu]

AFAIK GQL has never been on the roadmap.
@jgeewax, @beriberikix ?

[jgeewax]

👍 +1 to @dhermes -- I think we should not support it directly (at least not part of early milestones).

[jgeewax]

Can we maybe keep this open and add it for a later milestone? @silvolu

[silvolu]

Well, I closed it because I think we should not implement it.

[jgeewax]

I think the debate is open about whether we should eventually do this -- I certainly agree it shouldn't be done immediately...

[silvolu]

Re-opening it, but looks like you're currently the only one in favor of doing it :)

[dhermes]

Re-closing per discussion in meeting today with @jgeewax

[pcostell]

Can you provide the rational for not providing GQL?

[jgeewax]

I think the logic was "we should encourage people to use the ORM-ish thing we put together" -- and if someone wants to send a GQL query... it shouldn't be impossible, but I don't think it's a good idea...

Any rationale for why we'd want to expose the two different ways @pcostell ?

[pcostell]

Sometimes I feel that it's easier and cleaner to write a GQL query. More of an open question though -- if our client libraries aren't going to expose it, is it worth having in the Datastore API.

[jgeewax]

This actually is a great question... I don't know whether it's worthwhile -- and if it was, I'd expect it at a different endpoint ...

[dhermes]

@pcostell is my original comment incorrect?

GQL is an artifact of days gone by, i.e. what people thought was useful when the datastore was initially created.

[pcostell]

Yes, I believe that original comment is incorrect. I think we'll see some major changes in GQL over the next year which will make it more useful for customers.

Just as an FYI, GQL in Cloud Datastore was redesigned and isn't compatible with the GQL in the App Engine python SDKs. So when Cloud Datastore was introduced an explicit decision was made to provide GQL support even though it wouldn't be backwards compatible (thus not an artifact of initial Datastore).

/cc @Alfus

[dhermes]

Gotcher, thanks. Re-opening.

We (maybe just me?) were under the impression that GQL was past its usefulness. If that isn't the case, we're happy to implement. Do you see a library implementing all of the associated nouns/verbs or just supporting text queries? (It seems the GqlQueryArg will require special support.)

[pcostell]

Datastore RunQueryRequest has a GqlQuery argument. This argument takes a string which is the entire query. GqlQueryArg is just used to fill into the string any parameters (by number or by name). So I could imagine an API that looks like:

GqlQuery("SELECT * FROM MyKind WHERE a = @1 OFFSET @cursor", "myAValue", cursor=a_cursor)

Note the *args for numbered parameters and **kwargs for named parameters. These can get sent directly (+ some translation to proto for the arguments) to Datastore.

[jgeewax]

The bigger concern for me was that we wanted to keep people focused on our abstraction rather than writing GQL, so at best this is a "low priority" item -- but if you disagree, let me know.

I think it'd be a bad idea to encourage people to build apps that rely on writing lots of GQL queries -- the same way we encourage people to use an ORM rather than write SQL queries.

[jgeewax]

Hi @Fkawala You should probably post this over on StackOverflow to get help since this is really about the Python client library code.

[jgeewax]

Let's open a new issue for this -- this thread really isn't the right spot.

[dhermes]

Will go from v1beta2 to v1beta3, with the key distinction that in proto3 we can use a map for the named arguments.

I think we can make a subclass of datastore.Query and implement this pretty swiftly.