Would the ability to run sql before|after|around a migration be useful in rails?
33 views
Skip to first unread message
Jason Kenney
Mar 9, 2019, 10:14:51 AM3/9/19
to Ruby on Rails: Core
One issue I stumble on often is Postgres sql dependencies for advanced structure and rails migrations.
Scenic is helpful if its just views, but.... I actually think its approach can get in the way after you have something_vw_56.sql...
What would be REALLY helpful is if rails had built-in-hooks to just specify sql code that can run either:
- before the migration sequence
- after the migration sequence
- before a schema load (but after database creation)
- after schema load
- around a migration that has a particular tag associated with it (so you can drop specific materialized views, indexes, and recreate them only for a particular migration, and not on every single migration).
Sam Clopton
Sep 25, 2019, 8:14:42 PM9/25/19
to Ruby on Rails: Core
I'd like to at least see support for SQL view migrations in rails, especially since ActiveRecord already supports read only models for SQL views fairly well. I feel that scenic personally does a fairly good job, and I'd understand if the majority of rails maintainers don't want to add to the rails maintenance burden for SQL view migration support. What would wrapping the entire migrations sequence be used for? Better ways to wrap and augment schema generation could be improved IMO. Thoughts?
Colin Ross
Oct 10, 2019, 7:56:33 PM10/10/19
to Ruby on Rails: Core
There is a similar gem for handling triggers and functions named fx (https://github.com/teoljungberg/fx)
I believe the rationale for keeping this out of rails core has to due with two pretty big knock on effects it would have:
The migrator (including the command recorder and allowing for dynamically built reversals) would get terribly complicated if it had to support arbitrary sql getting injected
I believe the rationale for keeping this out of rails core has to due with two pretty big knock on effects it would have:
1) The mess of supporting across active record and endless false bug reports for things like "Custom function migration doesn't work in development but works in prod" b/c they are using sqlite in dev, etc.
2) It would lock apps to SQL-based dumps (db/schema.sql) in many cases, which is less than optimal from a code management point of view (at least imho) since the diffs tend to be very messy.
The migrator (including the command recorder and allowing for dynamically built reversals) would get terribly complicated if it had to support arbitrary sql getting injected
On Saturday, March 9, 2019 at 7:14:51 AM UTC-8, Jason Kenney wrote:
Reply all
Reply to author
Forward
0 new messages