Every now and again we need to change actual data in the production database. The first obvious option that comes to mind is to use a Rails migration, especially since the word “migration” is already in the task at hand, a “data migration.” But let’s talk about it some more and let me try to dissuade you from doing so. Looking the at Rails Guides for Active Records Migration, the first section sta
2016年2月16日「事例とデモで知るAWSへのデータベース移行」での AWS Database Migration Serviceご紹介の資料です。 2016/03/29更新:DMSが正式リリースされたため資料を更新しました。 2016/05/09更新:Redshitがサポートされたので資料を更新しました。また、CDCのサポートについてより明確になるように記載を追加しました(p.7) 2016/07/14更新:DMSのCDCの正式サポートとSSLサポート、マルチAZ機能追加、およびSCTの対象RDB追加等について更新しました。 2016/08/02更新:セキュリティグループについて古い記述が残っていたのを修正しましたRead less
イントロ rails のモデルは自動で id というカラムを作ってくれますが、これは常に INT 型。 BIGINT 型にしようとしたら、結構ハマったのでメモする。 使っている database はmysql です。 (postgresql だとこの罠は回避できるのだろうか?) tl;dr 普通に頑張ると... db:migrate と db:setup の実行結果が異なる migration ファイルの内容が、schema.rb に(一部)反映されないため db:migrate と db:setup の実行結果が異なると、 db:rollback ができなくなるので、辛くなりそう。 db:migrate か db:setup どちらかを使わない、という運用方式もある だが、面倒くさいので、そういうことを意識したくない 解決方法は 2 つ format_schema = :sql kami
add_milliseconds_to_mysql_and_activerecord_timestamps.md ActiveRecord: Store Milliseconds (or Microseconds) in Timestamps with Rails / MySQL Milliseconds in your Timestamps. We got 'em, you want 'em. Why Shit needs to be PRECISE LICENSE MIT milliseconds_migration.rb P SR�U �R�U class MillisecondsMigration < ActiveRecord::Migration # Include non default date stamps here # Key :table_name # value [:
Railsでmigrationを作成する時、changeメソッドだけが定義されていたり、upとdownメソッドの2つが定義されている時があります。 class AddColumnHoge < ActiveRecord::Migration def change end end class ChangeColumnHoge < ActiveRecord::Migration def up end def down end end こんな風に、migrationファイルを作成した時の名前で、生成されるclassのひな形が違います。 up/downについて upとdownメソッドは、migrateを実行した時の処理と、rollbackした時の処理を定義します。 upで変更したものは、downで元に戻るようにしておかないと、正しくrollbackできません。 class ChangeColumnH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く