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

Merged
merged 1 commit into from Nov 12, 2015

Conversation

Projects
None yet
7 participants
@yui-knk
Contributor

yui-knk commented Sep 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rails-bot

rails-bot Sep 12, 2015

r? @arthurnn

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

r? @arthurnn

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

+ end
+ end
+
+ def tables_and_views(name = nil, database = nil, like = nil) #:nodoc:

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 12, 2015

Member

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

@rafaelfranca

rafaelfranca Sep 12, 2015

Member

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

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 12, 2015

Member

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

@rafaelfranca

rafaelfranca Sep 12, 2015

Member

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

This comment has been minimized.

@yui-knk

yui-knk Sep 13, 2015

Contributor

it is my mistakes, I will fix them :)

@yui-knk

yui-knk Sep 13, 2015

Contributor

it is my mistakes, I will fix them :)

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Sep 12, 2015

Member

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?

Member

rafaelfranca commented Sep 12, 2015

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 comment has been minimized.

Show comment
Hide comment
@sgrif

sgrif Sep 12, 2015

Member

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

Member

sgrif commented Sep 12, 2015

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

@sgrif

This comment has been minimized.

Show comment
Hide comment
@sgrif

sgrif Sep 12, 2015

Member

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

Member

sgrif commented Sep 12, 2015

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

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 13, 2015

Member

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.

Member

senny commented Sep 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Sep 13, 2015

Contributor

@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?

Contributor

yui-knk commented Sep 13, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 13, 2015

Member

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.

Member

senny commented Sep 13, 2015

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 senny assigned senny and unassigned arthurnn Sep 13, 2015

@senny

This comment has been minimized.

Show comment
Hide comment
Member

senny commented Sep 13, 2015

/cc @matthewd

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 22, 2015

Member

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

Member

senny commented Sep 22, 2015

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

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 22, 2015

Member

@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.

Member

senny commented Sep 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 22, 2015

Member

@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.

Member

senny commented Sep 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Sep 23, 2015

Contributor

@senny I updated to only warning!

Contributor

yui-knk commented Sep 23, 2015

@senny I updated to only warning!

@@ -70,6 +72,10 @@ def drop_database(name) #:nodoc:
# Returns the list of all tables in the schema search path.
def tables(name = nil)
+ ActiveSupport::Deprecation.warn(<<-MSG.squish) if name
+ And passing arguments to #tables is deprecated.

This comment has been minimized.

@kamipo

kamipo Sep 23, 2015

Member

Looks like no need And.

@kamipo

kamipo Sep 23, 2015

Member

Looks like no need And.

This comment has been minimized.

@yui-knk

yui-knk Sep 23, 2015

Contributor

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

@yui-knk

yui-knk Sep 23, 2015

Contributor

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

@@ -626,9 +627,19 @@ def collation
end
def tables(name = nil) # :nodoc:
+ ActiveSupport::Deprecation.warn(<<-MSG.squish)
+ #tables of mysql adapter returns tables and views,

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

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

senny Sep 30, 2015

Member

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.
+ #tables of mysql adapter returns tables and views,
+ in Rails 5.1 this method will be changed to return only tables.
+ If you need tables and views, please use #data_sources.
+ #{"And passing arguments to #tables is deprecated." if name }

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

Can we split this off into a separate deprecation?

        if name
          ActiveSupport::Deprecation.warn(<<-MSG.squish)
            Passing arguments to #tables is deprecated without replacement.
          MSG
        end
@senny

senny Sep 30, 2015

Member

Can we split this off into a separate deprecation?

        if name
          ActiveSupport::Deprecation.warn(<<-MSG.squish)
            Passing arguments to #tables is deprecated without replacement.
          MSG
        end
activerecord/CHANGELOG.md
+
+ Reported on #21509, how views is treated by `#tables` are differ
+ by each adapters. To fix this different behavior, after Rails 5.0
+ is released, deprecate `#tables`.

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

Maybe:?

*   Deprecate `connection.tables` on the SQLite3 and MySQL adapters.
    Also deprecate passing arguments to `#tables`.

    The `#tables` method of some adapters (mysql, mysql2, sqlite3) would return
    both tables and views while others (postgresql) just return tables. To make
    their behavior consistent `#tables` will return only tables in the future.

    *Yuichiro Kaneko*
@senny

senny Sep 30, 2015

Member

Maybe:?

*   Deprecate `connection.tables` on the SQLite3 and MySQL adapters.
    Also deprecate passing arguments to `#tables`.

    The `#tables` method of some adapters (mysql, mysql2, sqlite3) would return
    both tables and views while others (postgresql) just return tables. To make
    their behavior consistent `#tables` will return only tables in the future.

    *Yuichiro Kaneko*
@@ -38,6 +38,7 @@ def data_source_exists?(name)
end
# Returns an array of table names defined in the database.
+ # Returning tables only or including views depends on each adapters.

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

I don't think it's worth to document this. It's been like this for a long time. I'd keep the docs for this method as is.

@senny

senny Sep 30, 2015

Member

I don't think it's worth to document this. It's been like this for a long time. I'd keep the docs for this method as is.

@@ -70,6 +72,10 @@ def drop_database(name) #:nodoc:
# Returns the list of all tables in the schema search path.
def tables(name = nil)
+ ActiveSupport::Deprecation.warn(<<-MSG.squish) if name
+ Passing arguments to #tables is deprecated.

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

Passing arguments to #tables is deprecated without replacement.

@senny

senny Sep 30, 2015

Member

Passing arguments to #tables is deprecated without replacement.

activerecord/test/cases/adapter_test.rb
+ if current_adapter?(:MysqlAdapter, :Mysql2Adapter, :SQLite3Adapter)
+ assert_deprecated { @connection.tables }
+ elsif current_adapter?(:PostgreSQLAdapter)
+ assert_deprecated { @connection.tables(:books) }

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

Let's split this into a separate test-case. Passing arguments is not just deprecated for the PostgreSQL adapter:

    if current_adapter?(:MysqlAdapter, :Mysql2Adapter, :SQLite3Adapter)
      def test_tables_returning_both_tables_and_views_is_deprecated
        assert_deprecated { @connection.tables }
      end
    end

    def test_passing_arguments_to_tables_is_deprecated
      assert_deprecated { @connection.tables(:books) }
    end
@senny

senny Sep 30, 2015

Member

Let's split this into a separate test-case. Passing arguments is not just deprecated for the PostgreSQL adapter:

    if current_adapter?(:MysqlAdapter, :Mysql2Adapter, :SQLite3Adapter)
      def test_tables_returning_both_tables_and_views_is_deprecated
        assert_deprecated { @connection.tables }
      end
    end

    def test_passing_arguments_to_tables_is_deprecated
      assert_deprecated { @connection.tables(:books) }
    end
@@ -308,6 +309,13 @@ def exec_rollback_db_transaction #:nodoc:
# SCHEMA STATEMENTS ========================================
def tables(name = nil, table_name = nil) #:nodoc:
+ ActiveSupport::Deprecation.warn(<<-MSG.squish)
+ #tables of sqlite3 adapter returns tables and views,

This comment has been minimized.

@senny

senny Sep 30, 2015

Member

same as above.

@senny

senny Sep 30, 2015

Member

same as above.

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Sep 30, 2015

Member

@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.

Member

senny commented Sep 30, 2015

@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.

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Oct 18, 2015

Contributor

@senny Sorry my late response. I changed where you commented, remove warnings. Is it better to update commit title and commit messages?

Contributor

yui-knk commented Oct 18, 2015

@senny Sorry my late response. I changed where you commented, remove warnings. Is it better to update commit title and commit messages?

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Oct 27, 2015

Contributor

@senny ping!

Contributor

yui-knk commented Oct 27, 2015

@senny ping!

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Oct 29, 2015

Member

If we change the meaning of tables to return only tables and have data_sources to return tables and views we need to do the same for table_exists? to check only tables and data_source_exists? to check both tables and views. This this would be a breaking change we need to find all the adapters where table_exists? did check both tables and views. These methods should then start to issue deprecation warnings and point the user to data_source_exists?.

In a later step we can then undeprecate table_exists? and change it's behavior to only check tables.

Member

senny commented Oct 29, 2015

If we change the meaning of tables to return only tables and have data_sources to return tables and views we need to do the same for table_exists? to check only tables and data_source_exists? to check both tables and views. This this would be a breaking change we need to find all the adapters where table_exists? did check both tables and views. These methods should then start to issue deprecation warnings and point the user to data_source_exists?.

In a later step we can then undeprecate table_exists? and change it's behavior to only check tables.

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Oct 29, 2015

Contributor

we need to do the same for table_exists? to check only tables and data_source_exists? to check both tables and views.

I agree :)

I think in Rails 5.0 it is better table_exists? check both tables and views (reported in #21509, this is current behavior) and issue deprecation warnings.
So I will make table_exists? to issue deprecation warnings. And replace all table_exists? in Rails with data_source_exists? (because now Rails check both tables and views by using table_exists?).

Contributor

yui-knk commented Oct 29, 2015

we need to do the same for table_exists? to check only tables and data_source_exists? to check both tables and views.

I agree :)

I think in Rails 5.0 it is better table_exists? check both tables and views (reported in #21509, this is current behavior) and issue deprecation warnings.
So I will make table_exists? to issue deprecation warnings. And replace all table_exists? in Rails with data_source_exists? (because now Rails check both tables and views by using table_exists?).

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Oct 29, 2015

Member

yes. We can't offer a real table_exists? for all adapters in Rails 5. To stay compatible we simply deprecate the table_exists? methods that also search views. This will migrate everyone over to data_source_exist?. Then we are able to change the meaning of table_exists?.

Member

senny commented Oct 29, 2015

yes. We can't offer a real table_exists? for all adapters in Rails 5. To stay compatible we simply deprecate the table_exists? methods that also search views. This will migrate everyone over to data_source_exist?. Then we are able to change the meaning of table_exists?.

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Oct 29, 2015

Contributor

@senny I updated!

Contributor

yui-knk commented Oct 29, 2015

@senny I updated!

@@ -67,11 +67,11 @@ def test_primary_key
def test_table_exists?
name = @omgpost.table_name
- assert @connection.table_exists?(name), "#{name} table should exist"
+ ActiveSupport::Deprecation.silence { assert @connection.table_exists?(name), "#{name} table should exist" }

This comment has been minimized.

@senny

senny Nov 5, 2015

Member

let's rewrite this test to use data_source_exists?. Make sure to also change the name.

@senny

senny Nov 5, 2015

Member

let's rewrite this test to use data_source_exists?. Make sure to also change the name.

end
def test_table_exists_wrong_schema
- assert(!@connection.table_exists?("#{@db_name}.zomg"), "table should not exist")
+ ActiveSupport::Deprecation.silence { assert(!@connection.table_exists?("#{@db_name}.zomg"), "table should not exist") }

This comment has been minimized.

@senny

senny Nov 5, 2015

Member

let's rewrite this test to use data_source_exists?. Make sure to also change the name.

@senny

senny Nov 5, 2015

Member

let's rewrite this test to use data_source_exists?. Make sure to also change the name.

@@ -90,7 +90,7 @@ def test_reset_with_transaction
end
def test_tables_logs_name
- @connection.tables('hello')
+ ActiveSupport::Deprecation.silence { @connection.tables('hello') }

This comment has been minimized.

@senny

senny Nov 5, 2015

Member

Should be the same behavior on data_sources. Can we rewrite that test to no longer use tables?

@senny

senny Nov 5, 2015

Member

Should be the same behavior on data_sources. Can we rewrite that test to no longer use tables?

This comment has been minimized.

@yui-knk

yui-knk Nov 7, 2015

Contributor

I think we should add test cases for #data_sources. Because test_tables_logs_name checks behavior of logging of #tables, and we should confirm this behavior is not regressed.

@yui-knk

yui-knk Nov 7, 2015

Contributor

I think we should add test cases for #data_sources. Because test_tables_logs_name checks behavior of logging of #tables, and we should confirm this behavior is not regressed.

@@ -100,7 +100,7 @@ def test_indexes_logs_name
end
def test_table_exists_logs_name
- @connection.table_exists?('items')
+ ActiveSupport::Deprecation.silence { @connection.table_exists?('items') }

This comment has been minimized.

@senny

senny Nov 5, 2015

Member

Should be the same behavior on data_sources. Can we rewrite that test to no longer use tables?

@senny

senny Nov 5, 2015

Member

Should be the same behavior on data_sources. Can we rewrite that test to no longer use tables?

This comment has been minimized.

@yui-knk

yui-knk Nov 7, 2015

Contributor

Maybe you mean "no longer use table_exists?" :)
Ditto, I think we should not remove this one. Because after Rails 5.0, #tables and #table_exists? will be still public API method. After Rails 5.1, behaviors of these methods will be changed but still be public API.

@yui-knk

yui-knk Nov 7, 2015

Contributor

Maybe you mean "no longer use table_exists?" :)
Ditto, I think we should not remove this one. Because after Rails 5.0, #tables and #table_exists? will be still public API method. After Rails 5.1, behaviors of these methods will be changed but still be public API.

end
end
def test_table_exists_quoted_table
with_schema_search_path(SCHEMA_NAME) do
- assert(@connection.table_exists?('"things.table"'), "table should exist")
+ ActiveSupport::Deprecation.silence { assert(@connection.table_exists?('"things.table"'), "table should exist") }

This comment has been minimized.

@senny

senny Nov 5, 2015

Member

I think all these tests should be rewritten to use data_source_exists?

@senny

senny Nov 5, 2015

Member

I think all these tests should be rewritten to use data_source_exists?

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 5, 2015

Member

@yui-knk patch is taking shape. Could you go over the tests and double check wether it should still be calling tables / table_exists? or be rewritten to use data_sources / data_source_exists?.

Going forward Active Record will in most cases only care about data sources. There's only a handful of places where tables and views are relevant. That's why probably most test should not exercise these paths but rather data_sources.

I commented on a couple of places to give you an idea but there are certainly more that need to change.

Member

senny commented Nov 5, 2015

@yui-knk patch is taking shape. Could you go over the tests and double check wether it should still be calling tables / table_exists? or be rewritten to use data_sources / data_source_exists?.

Going forward Active Record will in most cases only care about data sources. There's only a handful of places where tables and views are relevant. That's why probably most test should not exercise these paths but rather data_sources.

I commented on a couple of places to give you an idea but there are certainly more that need to change.

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Nov 7, 2015

Contributor

@senny
I will check wether it should still be calling tables / table_exists? 👍
In my opinion this commit should change tables to data_sources (table_exists? to data_source_exists ?) as little as possible. This commit add warnings to some methods and tables will be still public API method, so we should keep behavior tables method.

Contributor

yui-knk commented Nov 7, 2015

@senny
I will check wether it should still be calling tables / table_exists? 👍
In my opinion this commit should change tables to data_sources (table_exists? to data_source_exists ?) as little as possible. This commit add warnings to some methods and tables will be still public API method, so we should keep behavior tables method.

@@ -187,39 +187,39 @@ def test_schema_change_with_prepared_stmt
def test_table_exists?

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/adapters/mysql/schema_test.rb, we can change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/adapters/mysql/schema_test.rb, we can change.

@@ -284,9 +284,9 @@ def test_transaction

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/adapter_test.rb and activerecord/test/cases/adapters/postgresql/connection_test.rb, we can not change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/adapter_test.rb and activerecord/test/cases/adapters/postgresql/connection_test.rb, we can not change.

@@ -157,8 +157,10 @@ def change

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

In these migration tests, we should check table is created (or dropped), so can not change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

In these migration tests, we should check table is created (or dropped), so can not change.

@@ -405,9 +405,9 @@ def test_column_exists_on_table_with_no_options_parameter_supplied

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/invertible_migration_test.rb, can not.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/invertible_migration_test.rb, can not.

@@ -12,7 +12,9 @@ def setup

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/invertible_migration_test.rb, can not change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Same as activerecord/test/cases/invertible_migration_test.rb, can not change.

@@ -15,7 +15,7 @@ def setup
end

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

rename_table works only for table, it is better to use table_exists? here.

@yui-knk

yui-knk Nov 9, 2015

Contributor

rename_table works only for table, it is better to use table_exists? here.

@@ -313,9 +313,9 @@ def test_migrator_db_has_no_schema_migrations_table
_, migrator = migrator_class(3)

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

We should check here schema_migrations table.

@yui-knk

yui-knk Nov 9, 2015

Contributor

We should check here schema_migrations table.

@@ -224,7 +224,9 @@ class Barcode < ActiveRecord::Base
end

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Using if_exists: true allows us to remove table_exists? here, I will change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Using if_exists: true allows us to remove table_exists? here, I will change.

@@ -45,7 +45,7 @@ def test_view_exists
def test_table_exists

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

We should check behavior of tables, so can not change.

@yui-knk

yui-knk Nov 9, 2015

Contributor

We should check behavior of tables, so can not change.

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Nov 9, 2015

Contributor

@senny I checked and commented to each file. And updated!

Contributor

yui-knk commented Nov 9, 2015

@senny I checked and commented to each file. And updated!

@@ -967,7 +967,7 @@ def schema_migrations_table_name
end
def get_all_versions(connection = Base.connection)
- if connection.table_exists?(schema_migrations_table_name)
+ if connection.data_source_exists?(schema_migrations_table_name)

This comment has been minimized.

@kamipo

kamipo Nov 9, 2015

Member

It seems that schema_migrations_table_name table is a table, not a view. Should we use table_exists??

@kamipo

kamipo Nov 9, 2015

Member

It seems that schema_migrations_table_name table is a table, not a view. Should we use table_exists??

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

I agree, SchemaMigration.create_table uses connection.create_table internally, so I will change back it to table_exists?.

      def create_table(limit=nil)
        unless table_exists?
          version_options = {null: false}
          version_options[:limit] = limit if limit

          connection.create_table(table_name, id: false) do |t|
            t.column :version, :string, version_options
          end
          connection.add_index table_name, :version, unique: true, name: index_name
        end
      end
@yui-knk

yui-knk Nov 9, 2015

Contributor

I agree, SchemaMigration.create_table uses connection.create_table internally, so I will change back it to table_exists?.

      def create_table(limit=nil)
        unless table_exists?
          version_options = {null: false}
          version_options[:limit] = limit if limit

          connection.create_table(table_name, id: false) do |t|
            t.column :version, :string, version_options
          end
          connection.add_index table_name, :version, unique: true, name: index_name
        end
      end
@@ -21,7 +21,7 @@ def index_name
end
def table_exists?
- connection.table_exists?(table_name)
+ connection.data_source_exists?(table_name)

This comment has been minimized.

@kamipo

kamipo Nov 9, 2015

Member

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?.

@kamipo

kamipo Nov 9, 2015

Member

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?.

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Ditto :)

@yui-knk

yui-knk Nov 9, 2015

Contributor

Ditto :)

activerecord/test/cases/view_test.rb
@@ -87,7 +87,7 @@ def create_view(name, query)
end
def drop_view(name)
- @connection.execute "DROP VIEW #{name}" if @connection.table_exists? name
+ @connection.execute "DROP VIEW #{name}" if @connection.data_source_exists? name

This comment has been minimized.

@kamipo

kamipo Nov 9, 2015

Member

view_exists??

@kamipo

kamipo Nov 9, 2015

Member

view_exists??

This comment has been minimized.

@yui-knk

yui-knk Nov 9, 2015

Contributor

Yes 🙇

@yui-knk

yui-knk Nov 9, 2015

Contributor

Yes 🙇

Deprecate `#table_exists?`, `#tables` and passing arguments to `#talbes`
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.

And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.

senny added a commit that referenced this pull request Nov 12, 2015

Merge pull request #21601 from yui-knk/fix/ar_tables_without_view2
All `AR::ConnectionAdapters#tables` return only tables(exclude views)

@senny senny merged commit 19398ab into rails:master Nov 12, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 12, 2015

Member

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

Member

senny commented Nov 12, 2015

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

@yui-knk

This comment has been minimized.

Show comment
Hide comment
@yui-knk

yui-knk Nov 12, 2015

Contributor

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

Contributor

yui-knk commented Nov 12, 2015

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

@yui-knk yui-knk deleted the yui-knk:fix/ar_tables_without_view2 branch Nov 12, 2015

kamipo added a commit to kamipo/rails that referenced this pull request Nov 19, 2015

@bquorning bquorning referenced this pull request in zendesk/active_record_host_pool Dec 29, 2015

Merged

Compatibility with ActiveRecord 5.0 #14

yahonda added a commit to yahonda/oracle-enhanced that referenced this pull request May 20, 2016

Introduce `data_source_exists?` to return tables and views
also deprecate `#table_exists?`, `#tables` and passing arguments to `#tables`

Refer rails/rails#21601
rails/rails#21509

@yahonda yahonda referenced this pull request in rsim/oracle-enhanced May 20, 2016

Merged

Introduce `data_source_exists?` to return tables and views #841

kamipo added a commit to kamipo/rails that referenced this pull request Oct 2, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Oct 4, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Oct 28, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 2, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 3, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 6, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 10, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 20, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 27, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Nov 30, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Dec 11, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Dec 24, 2016

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

kamipo added a commit to kamipo/rails that referenced this pull request Jan 3, 2017

Deprecate passing `name` to `indexes` like `tables`
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

@nikonoll nikonoll referenced this pull request in soundcloud/lhm Jun 27, 2017

Open

Moved to date_source_exist from table_exists #145

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment