-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
BigQuery: [Primitive-ize API] SchemaField #8196
Comments
A good example of an API I think is nice and pythonic is the Kubernetes python API - for each object you can either supply:
|
We did recently add a slightly higher-level method for converting from JSON schema to list of SchemaField. I think it's reasonable to automatically convert in some of the classes/methods that currently accept a list of SchemaField. Might be a little bit tricky, though, since we can't do type inference since they'd both be lists. |
Nice, thanks. What's the method?
Yes, good point. I think the K8s API rebuilds the whole graph of objects, serializing / de-serializing where needed. That's not realistic to start, though. A hand-written imperative check doesn't seem satisfying either... |
Client.schema_from_json(file_or_path) is the related method. Not quite what you're asking for though, since it's for files. Edit: updated link to googleapis.dev |
Perfect, thanks! |
There's even precedent for accepting a JSON input in even the gRPC-based google-cloud-python libraries, so I'm hopeful there's a way we can do this in general. Maybe wherever we use to-api-repr in the client, try to do that and catch attribute error. If attribute error, treat it as the resource itself. Could make a good function in _helpers.py. |
Consistent with the recent work to allow the API to accept some primitives as well as specific objects, the schema argument to
LoadJobConfig
* could accept a list of dicts. Currently it requires constructing a bunch ofSchemaField
objects:We're trying to move to using the BQ Python API rather than subprocessing out to a shell with
bq
; it's got much better but it's still a bit Java-esque, and these are examples of times it's a tougher sell than constructing a string a sending it to bash. As ever, lmk if the API isn't designed for these cases and you'd encourage users to use bash.*this could also be a dict, though less of an imperative.
The text was updated successfully, but these errors were encountered: