allow customizing field names in BQ schema

[jhump]

No description provided.

[jhump]

I am migrating protos to use a different naming convention, but need the BQ schema to remain the same. This provides two ways to customize the field names:

1. At a message level, have all fields use their JSON name. This is most convenient for me since I also have code that relies on the JSON format. So, even though I need to rename fields, I am preserving their JSON name, so the messages' JSON format is unchanged. (I was previously already relying on the JSON name matching the BQ field name, so this will be perfect for me.)
2. I've also added another way to customize field names, which I think is most intuitive: a separate field option.

I saw that extension 1026 (table description, which is unused BTW) already had a TODO to register. Per extension best practices, I've added a new extension that is a message -- that way any future extensions can just be added as fields of that message.

In doing this, I went ahead and moved table description into the message and marked the other one as deprecated. But I also noticed that the table description extension isn't even used anywhere... Should it just be removed?

Anyhow, guidance on how to handle the message extension tag numbers would be appreciated.

[jhump]

@yugui, is this something you could take a look at? In the meantime, I'll need to maintain a fork of protoc-gen-bq-schema, because I really need to be able to refactor my protos without it mucking with my BQ schema.

[jhump]

@yugui, @sgammon, @mdittmer: Is this project still maintained? It's been a while since there were any commits, and no one has taken a look at this. Could someone please give a review? Or, if this project is not being maintained anymore and PRs will not be accepted, please let me know that, too.

[mdittmer]

For my part, I contributed a single patch to fix build back when a project of mine depended on this. (Said project no longer does depend on this.) I would not consider myself an "official maintainer" and will let others speak to ongoing maintenance.

[jhump]

Sorry if I spammed you, @mdittmer. In the search for someone that might be maintaining the project, I just looked at names of people that had commits on master.

[yugui]

Thank you for sharing your good use-case.

Unfortunately, as I commented in bq_table.proto, there's a problem which prevents us from adding a new option due to my fault. Do you have any good idea?

[jhump]

@yugui, I think I've made changes as requested. I don't know the right way to communicate the backwards-incompatible change, so I've just put it as a comment in the proto file.

I also added a test case that uses the old format for the extension, to make sure it can correctly fallback to parsing as a string, the old way. As I noted above, however, this is not a fool-proof solution. And I think it is likely that folks that upgrade the plugin may also end up upgrading their proto files at the same time (so this does little to help users with the compatibility issue).

Let me know what you think.

[yugui]

Merged.
Thank you for your great contribution.

[maguro]

I need to make all my BQ fields in the table required. It would be might handy to have something like

option (gen_bq_schema.bigquery_opts).default_require = true;