Railsのマイグレーションで複合キーのインデックスを貼る作業をした。 対象のRDBMSはMySQLでしかも、複合キーとなるカラムにTEXTがあったので、lengthを指定しなければいけなかった。 SQLで書くとこんな感じ。 ALTER TABLE target_table ADD INDEX additional_idx01( long_text(255) , saved_on )
migrationに関するkshibata101のブックマーク (9)
-
kshibata101 2018/07/11
-
【Rails・MySQL】MySQLのデータ型とRailsのマイグレーションファイルのデータ定義の対応まとめ - Qiita
マイグレーションファイルの作成業務をしていて、MySQLとの基本的な対応は解ったけど、 TinyIntとかMidiumTextってどうやって指定するの？となったので、対応を簡単にまとめました。 軽く検証 こんなマイグレーションファイルを実行して class CreateMigrationTest < ActiveRecord::Migration def change create_table :migration_tests,id:false do |t| t.string :string t.string :string_limit, :limit => 10 # limit => 数値でlimitを指定 t.string :string_nonnull, null:false #null:boolean で nullの可否を指定 t.text :tiny_text, :limit =
-
[Ruby on Rails] DBのカラムのデフォルト値を変更する方法
Ruby on Rails 3.2.3 にて、DBのカラムのデフォルト値を変更したのでメモ。 change_column_default(table_name, column_name, default) Sets a new default value for a column. Examples change_column_default(:suppliers, :qualification, ‘new’) change_column_default(:accounts, :authorized, 1) change_column_default(:users, :email, nil) ・引用元：ActiveRecord::ConnectionAdapters::SchemaStatements 例えば、articles テーブルの title カラムの定義が「String型、NUL
-
varchar Migration question for Ruby on Rails
I have created a new table including a column "note". The default is varchar(255) I believe but I wish to have this column be a text area vs. a field and to allow more data. I imagine that I would make this change in ActiveRecord::Migration file but I am curious as to the format. Do I simply change the varchar(255) to varchar(1000) for example? (if so what is the format? def self.up create_table :
-
ruby/rails/RailsGuidesをゆっくり和訳してみたよ/Rails Database Migrations - 株式会社ウサギィwiki
マイグレーション(Migrations) † マイグレーションは、構造的で組織的な方法でデータベースを変更するための、便利な方法です。 手作業でSQLの断片を編集できますが、他の開発者たちが実行する必要がある時、それを伝える責任があります。 productionマシンに対して次回デプロイする時に、どの変更が必要か追跡する必要があります。 Active Record は、どのマイグレーションが既に実行されたかを追跡しているので、やらなければならないのはソースを更新し rake db:migrate を実行することだけです。 Active Record はマイグレーションをうまく実行するでしょう。 またデータベースの構造に一致するように db/schema.rb を更新するでしょう。 マイグレーションはこれらの変換をRubyを使って記述することができます。 これについて素晴らしい
-
rails:migration [/dev/nullpo]
基本はrakeを使う // マイグレーション実行 $ rake db:migrate // 指定のバージョンのupを実行 $ rake db:migrate:up VERSION=XXXXXX // 指定のバージョンのdownを実行 $ rake db:migrate:down VERSION=XXXXXX // 一つバージョンを戻す $ db:rollback // 指定のバージョン分戻す $ db:rollback STEP=3 // 現在のバージョンを再適用 $ db:migrate:redo 色々やってると最初のバージョンからマイグレーションを実行できなくなっている事もある。そんな時はmigrateではなくschemaを使うといい。 // スキーマ（db/schema.rb）をロード $ db:schema:load // 現在のDBからスキーマを作成 $ db:schema:du
-
ActiveRecord の Migration で bigint を - はちゅにっき
つかい。。。たい？ そもそも bigint が本当に必要なのかを先に考えるべきじゃ。。。 とか思いつつも 「移行元の DB が bigint なんだよ」 というわけで、bigint を使うことに。 あれ？ところで (Rails とかで)、ActiveRecord 使って migration するとき、bigint ってどうやって指定するんだろう？ と疑問に思ったので、ソースコードを眺めてみたらあっさりとそれっぽい場所を発見。 active_record/connection_adapters/postgresql_adapter.rb 900行目付近 case limit when 1..2; 'smallint' when 3..4, nil; 'integer' when 5..8; 'bigint' end とゆーことで、migration ファイルの limit の値によって sm
-
ActiveRecord Migrations Without Rails | Strange Symphonies
Continuing exploring ActiveRecord without Rails, I thought I’d look into using Migrations without Rails. Once again, why? You already are using ActiveRecord without Rails Versionable instances of how your database looked like Database agnostic You forget how to crack out SQL code (happens to me, maybe too much ORM) You want migrations in non Ruby Projects boredom One thing I’d like to emphasize is
-
Rails 3.1 の migration の変更点について - おもしろwebサービス開発日記
またまたRails 3.1 ネタです。Rails 3.1 では migration ファイルのデフォルトフォーマットが変わりました。 rails g model blog title:string body:text としたとき、Rails 3.0 では下記のファイルが生成されます class CreateBlogs < ActiveRecord::Migration def self.up create_table :blogs do |t| t.string :title t.text :body t.timestamps end end def self.down drop_table :blogs end end Rails 3.1 では下記のファイルが生成されます。 class CreateBlogs < ActiveRecord::Migration def change cr
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました