つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
Managing db schema changes without downtime
At Discourse we have always been huge fans of continuous deployment. Every commit we make heads to our continuous integration test suite. If all the tests pass (ui, unit, integration, smoke) we automatically deploy the latest version of our code to https://meta.discourse.org. This pattern and practice we follow allows the thousands self-installers out there to safely upgrade to the tests-passed ve
Rails アプリでオンラインでカラムの削除やリネームを行うには - eagletmt's blog
前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら
gh-ost: GitHub's online schema migration tool for MySQL
Engineeringgh-ost: GitHub’s online schema migration tool for MySQLToday we are announcing the open source release of gh-ost: GitHub's triggerless online schema migration tool for MySQL. gh-ost has been developed at GitHub in recent months to answer a… Today we are announcing the open source release of gh-ost: GitHub’s triggerless online schema migration tool for MySQL. gh-ost has been developed at
Rails 5から導入されたmigration versioingについて
Rails 5から、migration versioingという機能が追加されました。 これは、generatorが生成するマイグレーションファイルに、Railsのどのバージョンで生成されたマイグレーションファイルなのかという情報を付与し、そのバージョン情報によりAPIの挙動を変える、というものです。 実際にRails 5.0.beta1でマイグレーションファイルを生成してみると、以下のような内容のファイルが生成されます。 $ ./bin/rails g model book name:string # db/migrate/20160124064808_create_books.rb class CreateBooks < ActiveRecord::Migration[5.0] def change create_table :books do |t| t.string :name t
RailsでDBのデータ変更はどこに書く？ - komagataのブログ
productionのデータ変更処理をmigrationに書くとrails_best_practicesに怒られる。 Rails Best Practices | Isolating Seed Data 怖話のコードで言えば下記の様なもの。 # encoding: utf-8 class InsertSeedToSound < ActiveRecord::Migration def up Sound.create!(id: 1, name: "鳥の鳴き声") Sound.create!(id: 2, name: "犬の鳴き声") Sound.create!(id: 3, name: "水滴") Sound.create!(id: 4, name: "カエルの鳴き声") Sound.create!(id: 5, name: "ラジオのチューニング") end def down Sound.d
GitHub - joker1007/redshift_simple_migrator: super simple migrator for AWS Redshift (and PostgreSQL)
Railsプロジェクトの初期開発フェーズでのDBスキーマ管理を見直す | Webシステム開発／教育ソリューションのタイムインターメディア
DBのスキーマ、皆様どのように管理されているでしょうか。 Railsを利用されている方の多くは、ActiveRecordのマイグレーションを利用して管理をされているかと思います。 私もいままでいくつかのRailsプロジェクトに関わってきましたが、 ほぼ全てのプロジェクトでActiveRecordのDBマイグレーションを利用してきました。 (一部のプロジェクトはActiveRecordを使っていないため、マイグレーションも独自のものを利用しています) ActiveRecordのマイグレーションでは、DBスキーマ変更の差分情報をマイグレーションスクリプトとして保存しておきます。例えば、新しいテーブル「users」を作成する場合は、下記のようなマイグレーションスクリプトを作成します。 class AddUsers < ActiveRecord::Migration def up # ここにマイグ
Rails で元に戻せないマイグレーションを書くときの作法: ActiveRecord::IrreversibleMigration - passingloopの日記
ActiveRecord のマイグレーションは，その中に up メソッドと down メソッドを書くことにより，データベースのスキーマを更新したり，変更を元に戻したりすることができ便利です．Rails 3.1 からは up, down を change メソッドにまとめて書くことができるようになりました． しかし，すべてが元に戻せるマイグレーションかというと，そうではないことがあります．たとえば， この図のように，integer だった vendor_code カラムを string に変更する場合，変更後のカラムに文字列を入れてしまうとマイグレーションで元に戻すことができません．文字列を数値に変換することができず，データが失われてしまうからです．このように，元に戻らないマイグレーションを書くときには，down メソッドで ActiveRecord::IrreversibleMigrati
Rails Best Practices | Double-check your migrations
When you generate a new migration, try it forwards and backwards to ensure it has no errors Many developers only check their migrations work on the forward step (rake db:migrate) but not so often on the backwards step (rake db:rollback). When I create a new migration, I like to do a little sanity check to be sure it works on both ways and it's free of typos or other errors. I just mean: rake db:mi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jalkoby/squasher: Squasher - squash your old migrations in a single command
RubyMotion でシンプルな CoreData のマイグレーションを行うコード
GitHub - soundcloud/lhm: Online MySQL schema migrations
HugeDomains.com