Menu
I have a rails app that has a particular table where the data and even the structure is dynamically generated outside of rails and ruby. This is by design, it is a special table where the structure is self-contained from the rest of active record and relationships. The models that work on it are also atomic. Again all by design, and purposeful. I don't not want a specific structure for this table, meaning that the column names and number of columns can change each time the table is initialized. If there are changes to the table structure I can manage the changes to my model class.
My issue is that the rails migration process seems to get in the way, and I don't want to have to keep stepping back and forth between migration and rollback, just to get the state of this single table reset.
The behavior I am looking for is literally every time I "generate" the data for this table I want to drop what table might already exist (in all environments: production, dev and test).
Is there a clear way to bypass the migration process? Or else create a special migration that is independent of the sequence of other migrations in the app?
The entire database is not disposable, but this one table is.
Thoughts on how I might achieve this behavior?
Rails 3, PostgreSQL database, git version control, heroku hosting
913
Rails Migration allows you to use Ruby to define changes to your database schema, making it possible to use a version control system to keep things synchronized with the actual code. Teams of developers − If one person makes a schema change, the other developers just need to update, and run "rake migrate".
You must rollback the migration (for example with bin/rails db:rollback ), edit your migration, and then run bin/rails db:migrate to run the corrected version.
I think the simple answer is "don't use migrations" -- they are designed to help you relatively gracefully extend an otherwise static database schema. A migration does many things beyond generating/executing the data definition language (DDL) of your database -- it knows how to go forward and backward, knows by a linkage between source code (schema.rb) and data (in the schema_migrations table) how to determine which migrations need to be run, and so on. All you need is the part that executes the DDL (which is, after all, just a kind of SQL).
And at least some of that part is here in the TableDefinition API. All of the infrastructure you might need seems to be present.
131
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
