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?`.
These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.
The goal is to provide the following introspection methods on the
connection:
* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)
Basically view tests for MySQL are same with
`test/cases/adapters/postgresql/view_test.rb`.
So move `test/cases/adapters/postgresql/view_test.rb` to
`test/cases/view_test.rb` and make them only run if
`current_adapter` supports writable view.
Currently, values for columns backing Active Record enums must be
specified as integers in test fixtures:
awdr:
title: "Agile Web Development with Rails"
status: 2
rfr:
title: "Ruby for Rails"
status: <%= Book.statuses[:proposed] %>
This is potentially confusing, since enum values are typically
specified as symbols or strings in application code. To resolve the
confusion, this change permits the use of symbols or strings to specify
enum values:
awdr:
status: :published
It is compatible with fixtures that specify enum values as integers.
Closes#10247.
The same goes for tables with an "id" column but without primary key constraint.
Reading from the view works without configuration. If you have an updateable view
you need to use `self.primary_key = ''`.
`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on
in adapter subclasses. Currently the flag only controls test execution.
/cc @yahonda
