8

データと構造さえもレールとルビーの外で動的に生成される特定のテーブルを持つレールアプリがあります。これは設計によるもので、残りのアクティブなレコードと関係から構造が自己完結している特別なテーブルです。それに取り組むモデルもアトミックです。繰り返しになりますが、すべて設計によるものであり、目的があります。このテーブルに特定の構造は必要ありません。つまり、テーブルが初期化されるたびに列名と列数が変わる可能性があります。テーブル構造に変更があった場合、モデル クラスへの変更を管理できます。

私の問題は、レールの移行プロセスが邪魔になっているように見えることです。この単一のテーブルの状態をリセットするためだけに、移行とロールバックの間を行ったり来たりする必要はありません。

私が探している動作は、文字通り、このテーブルのデータを「生成」するたびに、既に存在している可能性のあるテーブルを削除したいということです (すべての環境: 運用、開発、テスト)。

移行プロセスを回避する明確な方法はありますか? それとも、アプリ内の他の一連の移行から独立した特別な移行を作成しますか?

データベース全体は使い捨てではありませんが、この 1 つのテーブルは使い捨てです。

この動作をどのように達成できるかについて考えていますか?

Rails 3、PostgreSQL データベース、git バージョン管理、heroku ホスティング

4

2 に答える 2

2

簡単な答えは「移行を使用しない」だと思います。移行は、静的なデータベーススキーマを比較的適切に拡張できるように設計されています。移行は、データベースのデータ定義言語（DDL）の生成/実行以外にも多くのことを行います。移行は、前進および後退する方法を知っており、ソースコード（schema.rb）とデータ（schema_migrations表内）の間のリンクによって、どちらを決定するかを知っています。移行を実行する必要があります。必要なのは、DDLを実行する部分だけです（結局のところ、これは一種のSQLです）。

そして、その部分の少なくとも一部は、TableDefinitionAPIにあります。必要になる可能性のあるすべてのインフラストラクチャが存在しているようです。

于 2012-10-11T03:53:55.337 に答える
2

これは、テーブルの構築に使用される SQL/rails コマンドを含む rake タスク (使用しているように聞こえます) として設定できます。rake db:seed

于 2012-10-11T04:04:01.123 に答える