Deprecate schema name field in table config

[xiangfu0]

Apparently, it's more error-pruning and causing more confusion.

Plan is to always align table name with schema name.

Migration plan:
Controller can scan all tables with customized schema name and copy schema to table name, then update table config. In case the schema name is already occupied. We need to copy schema name to <table_name>_tmp, all table configs. Iterate all tables, then copy schemas from <table_name>_tmp to <table_name>, and update schema name again.

For any new table creation, if there is a reference schema, alway copy the schema then create table without schema name field.

Cc: @Jackie-Jiang

[Jackie-Jiang]

I'd suggest enforcing it instead of trying to handle the bad config by copying and renaming underlying. If we do this transparently, it can actually cause confusion because user might find their uploaded schema disappear, or the modification not reflected. Also, it is adding management overhead.
We can do an one time effort to move the existing schema, but for new tables, we simply disallow using different schema name. This way we can ensure a clean connection between table and schema

[xiangfu0]

Sounds good to me. Schema is also a deprecated field in table configuration, I think it's ok to enforce schema.

[eaugene]

@xiangfu0 @Jackie-Jiang

1. Can we keep a new REST API open for this action ? - Given a table name which allows a new schema with same name as table to be created from the existing schema if the table name and existing schema are different.
2. As the table name and schema are going to be the same , in the long run can we start deprecating the API's for schema specific actions & extending the scope of table config API to edit the schema as well?

[Jackie-Jiang]

@eaugene The current plan is to do a one time modification to all the existing tables without manually trigger the API for each individual table, one implementation example is #11574. Do you have concern on this approach?

[xiangfu0]

@xiangfu0 @Jackie-Jiang

1. Can we keep a new REST API open for this action ? - Given a table name which allows a new schema with same name as table to be created from the existing schema if the table name and existing schema are different.
2. As the table name and schema are going to be the same , in the long run can we start deprecating the API's for schema specific actions & extending the scope of table config API to edit the schema as well?

One thing I can think of is to have an option to copy schema from referred schema name to table name.
The behavior of multiple tables referring to the same schema should be deprecated.

[eaugene]

@eaugene The current plan is to do a one time modification to all the existing tables without manually trigger the API for each individual table, one implementation example is #11574. Do you have concern on this approach?

Thanks @Jackie-Jiang for sharing the PR . My only concern being having it as a periodic job is makes the action hidden from the table owners sight . Should we have it more transparent ?