Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port Datastore onto GAPIC #2746

Closed
bjwatson opened this issue Nov 17, 2016 · 22 comments
Closed

Port Datastore onto GAPIC #2746

bjwatson opened this issue Nov 17, 2016 · 22 comments
Assignees
Labels
api: datastore Issues related to the Datastore API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@bjwatson
Copy link

What

Port the gRPC code path for Datastore onto GAPIC. The package is available here.

Why

This is not a beta-blocker, since there already is gRPC code for Datastore, but it is preferred.

@bjwatson bjwatson added api: datastore Issues related to the Datastore API. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Nov 17, 2016
@dhermes
Copy link
Contributor

dhermes commented Nov 17, 2016

@bjwatson Two questions:

  1. Why doesn't the new package depend on google-gax>=0.15 (which has the new auth helpers)?
  2. Are we in a situation where some of the GAPIC packages depend on 0.13 <= google-gax < 0.14 while others depend on 0.14 <= google-gax < 0.15 (as this one does)?

@bjwatson
Copy link
Author

@dhermes Only because @geigerj says that he needs to make some small updates to the GAPIC generator for it to be compatible with google-gax>=0.15. He might be able to get that done today, and then we can build all packages with the newer google-gax dependency.

I thought I would get this in your hands right away, rather than waiting for the necessary fixes to support the newer auth helpers. However, if you think it's a more efficient use of your time to wait, then we can do that.

@dhermes
Copy link
Contributor

dhermes commented Nov 18, 2016

@bjwatson Sorry I didn't notice this until now, but the current form of grpc-google-cloud-datastore-v1 can't run without gRPC. This means we can't get access to the protobufs without forcing grpc to be installed.

Right now we support Protobuf-over-HTTP and Protobuf-over-gRPC, so we need access to the protobuf classes in use cases where gRPC isn't available (i.e. App Engine).

The generated protobuf classes currently live in datastore._generated, which is how we import them. In order to support gRPC we have datastore_pb2.py and datastore_grpc_pb2.py in the _generated module

/cc @jonparrott

@bjwatson
Copy link
Author

@dhermes Does googleapis/api-client-staging@6649c45 do what you need? Do you also need changes to setup.py? I see that your setup.py depends on grpcio regardless.

Note that this will become unnecessary once grpc/grpc#8056 is released in grpcio==1.1.0.

@dhermes
Copy link
Contributor

dhermes commented Nov 21, 2016

Yes it does do what I had in mind.

We had conditional checks in our setup.py, but @jonparrott discouraged that since it confuses wheel building. But maybe I am wrong on how I remember that.

AFAIK, even though grpcio is in our setup.py for packages like google-cloud-datastore, it doesn't stop from installing into a lib/ dir in an App Engine app. @jonparrott can confirm or deny or throw his hands up in sadness over packaging?

@theacodes
Copy link
Contributor

grpcio will indeed be vendored into lib for app engine and explode on import.

@dhermes
Copy link
Contributor

dhermes commented Nov 21, 2016

@bjwatson Ping me once released?

@geigerj
Copy link
Contributor

geigerj commented Nov 21, 2016

@bjwatson Is this a Datastore-specific hand-edit, or do we intend to provide these conditional imports across the gRPC packages we maintain? If it's the latter, we should figure out what the timeline for grpcio 1.1.0 is and whether we need to automate this in our tooling.

@dhermes
Copy link
Contributor

dhermes commented Nov 21, 2016

@geigerj @bjwatson We would love to see a new release of grpcio because of grpc/grpc#7849, so I am on team "pushing for release"

@bjwatson
Copy link
Author

@dhermes We're going to wait on porting Datastore to GAPIC until after the beta announcement. We discussed and we don't want to take any chances on destabilizing the google-cloud-python code for the four APIs. The only one that will go beta with GAPIC is Logging.

@dhermes
Copy link
Contributor

dhermes commented Dec 2, 2016

SGTM

@bjwatson bjwatson mentioned this issue Feb 22, 2017
7 tasks
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Feb 23, 2017
Towards googleapis#2746. This approach is to slowly transition from our
current approach to use the GAPIC generated surface.

It is unfortunately tangled quite a bit (partly because we
may have too much mocked in the tests).
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Feb 24, 2017
Towards googleapis#2746 (as is googleapis#3064). This approach is to slowly transition
from our current approach to use the GAPIC generated surface.

These unit tests weren't so bad to update. I did "editorialize"
as I went, downgrading constants to just variables, renamining
for PEP8, etc.
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Feb 24, 2017
Towards googleapis#2746. This approach is to slowly transition from our
current approach to use the GAPIC generated surface.

It is unfortunately tangled quite a bit (partly because we
may have too much mocked in the tests).
@lukesneeringer lukesneeringer added the priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. label Feb 28, 2017
@bjwatson
Copy link
Author

bjwatson commented Mar 2, 2017

@lukesneeringer @dhermes If we're blocking the x-goog-api-client header updates on this issue, then it's P0.

@dhermes
Copy link
Contributor

dhermes commented Mar 2, 2017

@bjwatson Those are already in for HTTP. I can get them in to the gRPC transport before the process is finished (#3066 and #3064 will give you an idea of what the process looks like).

@bjwatson
Copy link
Author

bjwatson commented Mar 2, 2017

Ok, thanks Danny!

dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 6, 2017
This is to prepare for a removal of the Connection class
(relates to googleapis#2746 and googleapis#3105).
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 6, 2017
This is progress towards googleapis#2746 and makes Connection() act
as a proxy for the contents of Client (as intended).
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 6, 2017
This is progress towards googleapis#2746 and makes Connection() act
as a proxy for the contents of Client (as intended).
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 6, 2017
This is progress towards googleapis#2746 and makes Connection() act
as a proxy for the contents of Client (as intended).
@lukesneeringer
Copy link
Contributor

@dhermes This is now done, question mark?

@dhermes
Copy link
Contributor

dhermes commented Mar 17, 2017

Almost. One follow-up PR, coming in hot.

dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 17, 2017
dhermes added a commit to dhermes/google-cloud-python that referenced this issue Mar 17, 2017
@bjwatson
Copy link
Author

Woo hoo! Great job, Danny!

@lukesneeringer @dhermes Does this mean that we'll have the new HTTP headers working for Datastore as soon as this is published?

@lukesneeringer
Copy link
Contributor

I believe we have the HTTP headers now. But, yes.
I am thinking a quick umbrella release next week as part of the GA effort, but we can push a 0.23.x for this if we want it sooner.

@dhermes
Copy link
Contributor

dhermes commented Mar 17, 2017

I just did a

$ git diff datastore-0.23.0 -- datastore/google

and the only change that is in the public interface is the addition of use_gax in the Client constructor.

@lukesneeringer
Copy link
Contributor

Sure, but it is a huge under-the-hood change, because those with GRPC support are suddenly using the GRPC transport now.

@dhermes
Copy link
Contributor

dhermes commented Mar 17, 2017

@lukesneeringer We already had the gRPC transport (for many releases), it was just the raw stub produced by the protoc plugin rather than the DatastoreClient which wraps that very same class.

@lukesneeringer
Copy link
Contributor

Okay.

richkadel pushed a commit to richkadel/google-cloud-python that referenced this issue May 6, 2017
Towards googleapis#2746 (as is googleapis#3064). This approach is to slowly transition
from our current approach to use the GAPIC generated surface.

These unit tests weren't so bad to update. I did "editorialize"
as I went, downgrading constants to just variables, renamining
for PEP8, etc.
richkadel pushed a commit to richkadel/google-cloud-python that referenced this issue May 6, 2017
Towards googleapis#2746. This approach is to slowly transition from our
current approach to use the GAPIC generated surface.

It is unfortunately tangled quite a bit (partly because we
may have too much mocked in the tests).
richkadel pushed a commit to richkadel/google-cloud-python that referenced this issue May 6, 2017
This is to prepare for a removal of the Connection class
(relates to googleapis#2746 and googleapis#3105).
richkadel pushed a commit to richkadel/google-cloud-python that referenced this issue May 6, 2017
This is progress towards googleapis#2746 and makes Connection() act
as a proxy for the contents of Client (as intended).
richkadel pushed a commit to richkadel/google-cloud-python that referenced this issue May 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: datastore Issues related to the Datastore API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

5 participants