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
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.