Use view without namespace when dumping schema. #327
Conversation
Without this, default behavior of `rake db:schema:load` is broken becuase Activerecord config option `schema search path` for Postgres adapters is automatically used to identify where is the schema being loaded to; By explicitly adding the namespace/search_path in the schema.rb it's wrong as you can run rake db:migrate from multiple computers and configurations which result in namespace_from_pc_1.view_name and namespace_from_pc_2.view_name on different commits. + Added a new private method unscoped_view to make sure to not include the namespace when dumping the schema name + Updated tests to make sure the namespace is excluded rather than included.
|
@rapito This is in direct conflict with #152, which introduced this behavior. Honestly, I have zero intention of ever using Scenic with multiple namespaces so I'm not sure what the correct solution is here. Can you convince me and/or @calebhearth which decision is correct? I see your point that we can allow the schema search path to determine this for us. However, what about the case where your app actually uses multiple schemas? If we rely on schema search path alone, wouldn't all views be created in whatever the first listed schema is when in reality we might want some in the first listed schema and some others in the second? How does Rails itself handle this with tables? cc @Willianvdv |
|
To that end I would suggest making the scenic migration accept optional parameters to include the schema search path. And to still allow specifying schemas, the method should not include the schema on the scenic view name but as an argument of the method. create_view "tablename", schema: "schema_name"The gem would translate that to "schema_name.tablename" when executing it. Furthermore, the schema parameter should only be set if the gem config option Imo, Ideally the primary feature that the gem should support is creating the scenic views. Everything else should be secondary such as supporting multiple schemas, and if they break default behaviors or patterns then they should be optional. |
Why?
Without this, default behavior of
rake db:schema:loadis broken because ActiveRecord config optionschema_search_pathfor Postgres adapters is automatically used to identify where is theviewbeing loaded to; By explicitly adding the namespace/search_path in the schema.rb it's wrong as you can runrake db:migratefrom multiple computers and configurations which can result innamespace_from_pc_1.view_nameandnamespace_from_pc_2.view_nameon different commits.Scenarios with issues
database.ymlusing an environment variable such asschema_search_path: <%= ENV['PG_DB_SCHEMA'] %>my_viewexport PG_DB_SCHEMA=my_schema_1export PG_DB_SCHEMA=my_schema_2rake db:migratewhich generates "my_schema_1.my_view" on schema.rbrake db:migratewhich generates "my_schema_2.my_view" on schema.rbPG_DB_SCHEMA=my_ci_schema_3runrake db:schema:load, it fails.Changes
Extra
An additional justification is that
schema.rbdoes not include namespaces ever, and the default Rails/Activerecord behavior should be conserved.Fixes: #325