NDB: Start in on ndb.client.Client

[chrisrossi]

This is patterned off of datastore.client.Client and depends heavily on google.cloud.client.

[dhermes]

@chrisrossi I'm not clear why this special Client class is needed. A parallel to ndb would be https://github.com/googleapis/google-cloud-python-happybase, which doesn't define a Client of it's own (but does have a similar metaphor).

[chrisrossi]

@dhermes

@chrisrossi I'm not clear why this special Client class is needed. A parallel to ndb would be https://github.com/googleapis/google-cloud-python-happybase, which doesn't define a Client of it's own (but does have a similar metaphor).

A couple of days ago, before starting this, I sent around an email entitled "NDB client story", where I was pretty much fishing for exactly this kind of input. Did you see that?

I can look at happybase--I'm not familiar with it at the moment. Basically, if we're going to interact with datastore, we need to get credentials, figure out the project/app, and possibly get a namespace. Since this is just a layer on datastore, I looked to datastore for the model on how to do it. I'm not wed to anything in particular, but I try not to invent new idioms if there is one already available, and I figured datastore probably represented some kind of "best practice" for Google APIs.

[chrisrossi]

@dhermes

@chrisrossi I'm not clear why this special Client class is needed. A parallel to ndb would be https://github.com/googleapis/google-cloud-python-happybase, which doesn't define a Client of it's own (but does have a similar metaphor).

A couple of days ago, before starting this, I sent around an email entitled "NDB client story", where I was pretty much fishing for exactly this kind of input. Did you see that?

I can look at happybase--I'm not familiar with it at the moment. Basically, if we're going to interact with datastore, we need to get credentials, figure out the project/app, and possibly get a namespace. Since this is just a layer on datastore, I looked to datastore for the model on how to do it. I'm not wed to anything in particular, but I try not to invent new idioms if there is one already available, and I figured datastore probably represented some kind of "best practice" for Google APIs.

I've looked at HappyBase this morning and it has a Connection object which is the moral equivalent of the Client object here. We need some way to manage the little bit of state that gets used to talk to Datastore. google.cloud.datastore uses a Client object and it makes sense to me for us also to use a Client object that is the parallel of that.

[dhermes]

@chrisrossi I'd say push on with Client, but try to think of a way not to have this if we can avoid it. ndb's design is essentially going to force global state to be stored on the module, joy!

[chrisrossi]

@chrisrossi I'd say push on with Client, but try to think of a way not to have this if we can avoid it. ndb's design is essentially going to force global state to be stored on the module, joy!

@dhermes I'm reasonably confident we can contain all the state we need in client.Client and the thread locals in _runstate.

[dhermes]

@chrisrossi You have an uncovered branch in conftest.py, so you need a no cover pragma?

[chrisrossi]

@dhermes Yep, fixed.

[dhermes]

LGTM