All AR::ConnectionAdapters#tables return only tables(exclude views)

[yui-knk]

As reported on #21509,
tables method of adapters for mysql and sqlite include view
but for postgresql does not include. This commit fix all of them
to return only tables(exclude views). Close #21509.

This commit includes these fixes:

Implement tables_and_views for mysql and sqlite

tables method of adapters for mysql and sqlite has two
functions.

1. Return all tables names
2. Return all tables names which matches to database name or table name
   (specified by argument)

Move no. 2 function to tables_and_views method.

Change arguments of tables method

Now the responsibility of tables is to return all tables names,
so change this method to be argument-less method.

Change some tests

• test_tables_quoting in activerecord/test/cases/adapters/mysql2/schema_test.rb
  This test asserts database name is quoted internally. tables_and_views accepts
  database name. So change from @connection.tables to @connection.tables_and_views.
• test_tables_logs_name in activerecord/test/cases/adapters/sqlite3/sqlite3_adapter_test.rb
  This test asserts what SQL is executed. SQL created by tables is changed, so change sql
  used to assertion.

[rails-bot]

r? @arthurnn

(@rails-bot has picked a reviewer for you, use r? to override)

[rafaelfranca]

I don't think name is being used anywhere so lets remove it.

[rafaelfranca]

Also can we make this method private? It is not being used anywhere besides test.

[yui-knk]

it is my mistakes, I will fix them :)

[rafaelfranca]

I'm not sure. This is a huge change on behavior. tables is public API and I bet someone is depending in the fact that it returns also view. I vote to just document that it returns views.

@sgrif @senny @matthewd thoughts?

[sgrif]

This will break apps I have worked on in the past for sure.

[sgrif]

The inconsistency between PG and the rest bothers me as well, though.

[senny]

We should deal with that inconsistency somehow. It's quite the difference in behavior and client code for all adapters can never be sure what they'll get. I think there's a handful of issues on GitHub about that behavior.

One approach that comes to mind would be deprecating tables() for Rails 5 in favor of tables(views: true) and tables(views: false). This would force callers to be specific about what they want and we can maintain the current inconsistent behavior of tables(). At a later stage (Rails 5.1), we can then move tables() to the new behavior. Either returning both views and tables or just tables. Whichever is preferable.

[yui-knk]

@rafaelfranca

bet someone is depending in the fact that it returns also view

Sure. But at the same time, I think someone is depending in the fact that it does not return view (postgresql users). I am not sure changing all adapters to returns table + view is better than only return table.

@senny
Now #21609 PR is posted. So user can views + talbes to get both of them. I think tables should return only table in the future. Is it better add views option to tables (tables(views: true)) and waning for Rails 5.0?

[senny]

I need to have a better look where tables is used but my first reaction is that tables should return both tables and views. My thinking is that at it's core a view is a virtual table. Many features that work with a table can also work with a view. That's just a guess though, we need to look through our current usage to determine what's better.

I like the idea of passing in view: true and view: false because this let's us make the change in a completely backwards compatible manner. In the first step we can deprecate calling tables without any options and describing the future behavior change. After that it's save to change tables without any arguments.

[senny]

/cc @matthewd

[senny]

@yui-knk #21609 was merged, is there anything that you'd like to update?

[senny]

@yui-knk please hold changes to this PR, I'm currently working on a patch that should make the situation for tables more clear. I'll ping you on the PR when it's ready.

[senny]

@yui-knk I merged my patch. We can now put in place the necessary deprecations to change the behavior of #tables. I suggest the following:

• Deprecate #tables on all the adapters, where views and tables are returned in favor of data_sources but keep the current implementation.
• Keep #tables as is on adapters that only return tables.

Then after 5.0 lands no-one should be relying on #tables behavior with views any longer and we can safely change the implementations and remove the deprecations.

This means that in the transition phase. Basically 5.0 some adapters won't have a method to only get tables. But that shouldn't be too much of a problem as that is the same situation that we have right now.

[yui-knk]

@senny I updated to only warning!

[kamipo]

Looks like no need And.

[yui-knk]

Thank, I fixed it. Copy & paste is evil 👿

[senny]

What about the following wording:

    #tables currently returns both tables and views.
    This behavior is deprecated and will be changed with Rails 5.1 to only return tables.
    Use #data_sources instead.

[senny]

@yui-knk running the update produces tons of warnings. We should change our internals to no longer depend on any of the deprecated behavior. This means to also touch on the behavior of table_eixsts? and look into deprecations on that end as well.

[kamipo]

SchemaMigration#table_exists? is used for SchemaMigration#create_table and SchemaMigration#drop_table. It seems that should use table_exists? rather than data_source_exists?.

[yui-knk]

Ditto :)

[senny]

🎉 @yui-knk thank you for working on this! 💛

[yui-knk]

@senny 🎉 thanks for your review !!!! 😍