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: 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: > > 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). > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-core/bcdb0d3a-7261-4fbb-a544-b1ca3be84a58%40googlegroups.com.
