5

移行中に実行される独自のタイムスタンプメソッドを作成しようとしています。配置されているものは、フィールドにNOT_NULL制約を追加しますが、私は本当にそれを望んでいません。

私が抱えている問題は、マルチスキーマのデータベースを持っていることです。各主要クライアントが独自のスキーマを取得する場所。新しいクライアントをオンボードするときは、新しいテナントレコードを作成してから、新しく作成されたスキーマの移行を実行します。

新しいスキーマは、もちろんデータがない場合を除いて、他のスキーマのテーブルの正確なコピーであると想定されています。

私が実行した最後の移行は、少し古いバージョンのrailsを使用していました。まだ3代ですが、少し古いです。タイムスタンプを作成したとき、それらはNULL可能でした。先日（新しいレールで）移行を実行したとき...まあ、すべてのフィールドがNOT_NULLになりました

update_atは、レコードが作成されたときではなく、更新されたときにのみ入力されるという考えで開発されたコードがあります。（サードパーティのアプリとデータベースの「関数」がレコードを作成します）。レコードを作成するサードパーティのアプリとデータベース関数は、新しいスキーマに分類されます...すべてのテーブルのすべてのNOT_NULL制約を削除しました。手動ですが、将来のすべてのテーブルが修正されるように、移行タスクにクリーンアップを直接書き込む必要はありません。

最善の方法は、変更されたタイムスタンプメソッドをオーバーライドして、既存のコードを壊さないメソッドに戻すことだと思いました。

したがって、元に戻す/オーバーライドする必要がある理由があります。
私の質問は...メソッドをオーバーライドするにはどうすればよいですか。それへの明確なクラスパスが表示されず、オーバーライドする方法が正確にわかりません。

4

2 に答える 2

4

これをモンキーパッチに入れて… 簡単！

class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::TableDefinition
  def timestamps(*args)
    options = args.extract_options!
    column(:created_at, :datetime, options)
    column(:updated_at, :datetime, options)
  end
end

マニークが言ったように。この「修正」により、レールへの更新は無視されます。

しかし、彼の最初のオファーは同じです。また、彼の修正に対応するには、以前の移行に戻り、「タイムスタンプ」を新しいコードに置き換える必要があります。それに加えて、将来の自動生成された移行もすべて置き換える必要があります。

それはDRYには合わないと思います。SPOTにも合いません。

ただB慎重に！

于 2013-03-25T05:21:01.327 に答える
1

どうしたの：

create_table :foo do |t|
   t.text :bar
   t.datetime :created_at
   t.datetime :updated_at
end

?

于 2013-03-24T22:03:58.457 に答える