introduce conn.data_source_exists? and conn.data_sources.
#21715
Conversation
|
@rafaelfranca @sgrif what do you guys think? |
senny
force-pushed
the
introduce_data_sources
branch
2 times, most recently
from
1afa301
to
390da81
Compare
senny
force-pushed
the
introduce_data_sources
branch
from
390da81
to
5a5ffaf
Compare
|
👍 Here, we distinguish table-qua-table from "thing we can run queries against" -- sometimes we need to know whether a thing is a table or a view (or something else), but most of the time, we want to treat them interchangeably. Thus, better to give that concept a name, and address it unambiguously... at least in the closer-to-the-metal layers: models can still use "table" when they actually mean Technically the right word for this would be |
|
👍 |
|
Looks good to me. |
| @@ -23,6 +23,20 @@ def table_alias_for(table_name) | |||
| table_name[0...table_alias_length].tr('.', '_') | |||
| end | |||
|
|
|||
| # Returns the relations names usuable to back Active Record models. | |||
| # Defaults to all #tables and #views. | |||
There was a problem hiding this comment.
I feel it is not "defaults".
For example is it better: ?
data sources mean all tables and views
There was a problem hiding this comment.
plus in Changelog
These methods determine what relations can be used to back Active Record models (usually tables and views).
Do we intend that user can override data_sources when they would not use views, they would not use tables, or they would use some lists of table names as Active Record back?
If so, senny's comment is reasonable and how about to add these comments
You can override this method if you would not use views (or tables) as Active Record back.
def data_sources
tables
end
There was a problem hiding this comment.
@yui-knk it's not so much about wether the user can overwrite these methods but the adapters can. We can't say for sure that every adapter will have working views and tables as data source.
|
|
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)
senny
force-pushed
the
introduce_data_sources
branch
from
5a5ffaf
to
152b85f
Compare
introduce `conn.data_source_exists?` and `conn.data_sources`.
…ata_sources" introduce `conn.data_source_exists?` and `conn.data_sources`. Conflicts: activerecord/CHANGELOG.md activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb activerecord/lib/active_record/connection_adapters/schema_cache.rb activerecord/lib/active_record/schema_dumper.rb activerecord/lib/active_record/type_caster/connection.rb activerecord/test/active_record/connection_adapters/fake_adapter.rb activerecord/test/cases/adapters/postgresql/schema_test.rb
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.tablesin the future (#21601) to only return tables andno views. Same for
conn.table_exists?.The goal is to provide the following introspection methods on the
connection:
tablestable_exists?viewsview_exists?data_sources(views + tables)data_source_exists?(views + tables)ToDo
#data_sourcesand#data_source_exists?implementation is possible for specific adapters. Instead of queryingviewsandtablesseparately.