You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BigQuery: expose public helper method to convert a list of schema fields to/from a list of schema dictionaries (JSON) #3723
I've received some feedback asking how to take a schema from the client library and save it to a JSON file. One reason to do this is the bq command-line tool accepts a schema file, formatted like
It would be pretty trivial to adapt them to skip / overlook the missing fields key. How would you envision this for the library API surface? Methods on the Table class to load / store the schema to a file? What about schema for e.g. query jobs?
Since this is something that would act on lists, it doesn't really correspond to an existing resource representation that we have. Do we put static helper functions in the top-level google.cloud.apiname package, generally?
Activity
tseaver commentedon Aug 3, 2017
We already have non-public helper methods which render / parse schemas to / from a format like:
{"fields": [ {"name": "name", "type": "string", "mode": "required"}, {"name": "gender", "type": "string", "mode": "nullable"}, {"name": "count", "type": "integer", "mode": "required"} ]}It would be pretty trivial to adapt them to skip / overlook the missing
fieldskey. How would you envision this for the library API surface? Methods on theTableclass to load / store the schema to a file? What about schema for e.g.queryjobs?tswast commentedon Aug 3, 2017
There are two main use cases that I've heard about
tswast commentedon Aug 3, 2017
Since this is something that would act on lists, it doesn't really correspond to an existing resource representation that we have. Do we put static helper functions in the top-level
google.cloud.apinamepackage, generally?tswast commentedon Aug 3, 2017
Going through the issues I see that this is a duplicate of #3419.
Closing this issue in favor of that one.