はじめに Rails チュートリアルなどで、Railsの勉強をしていてフォームの実装をしていた時に、フォームを追加したい場合、当然カラムもしなければいけません。色々調べていたら勉強になったので、まとめておきます。 環境 この記事では以下の環境（2018年6月18日時点）で動作確認できました。 Ruby: 2.4.1 Rails: 5.0.7 現状 micropostsという名前のテーブルに、新たにstatusというカラムを追加したい場合 mysql> describe microposts; +------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+----
Railsでアプリ開発中にバリデーションをかけようと思い、 一意性制約（テーブル内で重複するデータを禁止する）の記述について、ネットで調べていると、 unique:true uniqueness: true上の２つで出てきて、どっち！？違いはなに！？ってなったんで調べてみました。 まず前提として一意性制約には以下の2パターンのやり方があるという事。 ①アプリケーション側に設定➔モデルに記述（uniquness:true) ②DB側に設定➔マイグレーションファイルに記述（unique:true） まず①についてはこんな書き方 class User < ApplicationRecord validates :name, uniqueness: true end user.rb 続いて②についてはこんな感じ class AddEmailToUsers < ActiveRecord::Migra
はじめに 背景 ActiveRecord::AttributeMethods::Dirtyとは メソッド一覧 メソッド名の変遷 活用に向けた検証 検証に使用したモデル Dirtyの活用例 実現したかったこと/実装例 Dirtyの活用したサンプルコード おわりに 参考 はじめに はじめまして、スタメンでエンジニアをしているショウゴです。普段は、バックエンドグループでRuby on Railsを用いてバックエンドの開発を主に担当しています。 今回の記事では、ActiveRecordのattributeの変更状況を確認できるRailsのActiveRecord::AttributeMethods::Dirtyモジュールの使い方の検証結果と活用例を紹介します。 背景 今回、特定のカラムの値を変化させて、ステータスの変更・管理を行っているモデルに対して新たなバリデーションを実装する作業の中で、特定の
0. はじめに 0-0. はじめに 以前、「Rails における内部結合、外部結合まとめ」や「ActiveRecordにおけるGROUP BYの使い方」という記事を書いたのですが、サブクエリに関して、特にサブクエリと結合するときにActiveRecordでどう記述すればいいのか逡巡したときがあったので、備忘録的に記述します。 また、Otemachi.rb#7にて、「いまさらサブクエリ」というタイトルでLTも行ったので、こちらも参考になるかもしれません。 0-1. RubyとRailsとPostgreSQLのバージョン $ ruby -v ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16] $ rails -v Rails 5.2.0 => SELECT version(); version ---------------
はじめに 多くのRails初学者はSQL文をあまり意識せずActive Recordを使用してしまっているかと思います。しかしデバッグ作業や複雑な絞り込みには生のSQL文を利用する機会はそれなりに多く、また実行されているSQLを理解していないままだと気づかぬうちに非効率なコードを書いてしまっている可能性があります。 そこで本記事ではActiveReocordメソッドで実行されているSQL文をまとめてみました。 メソッドとSQL文 find User.find(1) # SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1 User.find([2,3,4]) # SELECT `users`.* FROM `users` WHERE `users`.`id` IN (2, 3, 4) findメソッドでは「引数をidに持つ
0. はじめに Qiitawはじめ、さまざまなところでRailsのActiveRecordの内部結合や外部結合に関する記事がありますが、それらがまとまって存在していると良いリファレンスとなるのではないかと思い本記事を作成しました。 また、Rails5で動作確認しておきながら、Rails5から追加されたleft_outer_joinsなどは載せてません。今後、載せていきたいと思います。 group byやサブクエリ（副問い合わせ）に関しては下記もご参照ください。 ActiveRecordにおけるGROUP BYの使い方 ActiveRecordでサブクエリ（副問い合わせ）と内部結合 0-1. RubyとRailsとPostgreSQLのバージョン $ ruby -v ruby 2.2.4p230 (2015-12-16 revision 53155) [x86_64-darwin15] $
でカラムの削除をしようとすると、外部キー制約に引っかかるため削除ができない。 「カラム名:references」を後尾につけると、remove_reference と remove_foreign_key が自動付与されるので良い。 $ rails generate migration remove_カラム名_from_テーブル名 カラム名:references $ rails g migration remove_content_from_item content:references class RemoveContentIdFromItem < ActiveRecord::Migration def change remove_reference :items, :content, index: true remove_foreign_key :items, :contents en
Activerecordを使ってるとき、関連(Association)のあるmodel同士をまとめて取得したい時がけっこうある。そんな時、includesやjoinsを使えば効率良くデータを取得出来るんだけど、実はこの二つは振る舞いや特徴が全然違ってたりする。ややこしい気がしたので、ここでちょっとまとめておく。 先に結論を書いておくと、基本的には includesは先読みしてキャッシュしておく。 joinsはただINNER JOINしてくれる。 と思っておけばOK。 ちなみに、railsのversionは4.1.0。Web上に落ちてる情報は古いせいか若干現状の挙動とは違ってたりしたので、気をつけた方が良さそう。 includes includesはデータの先読みをしてくれる。その為、関連modelに対する参照を持ちたい場合に使う。そう言われてもよくわからないと思うので、実際に使用例を見てみ
RailsでActiveRecord::NoEnvironmentInSchemaErrorが出たときの原因と対応方法の備忘録。Railsのバージョンは5.1.5です。 開発環境でDBを作り直す際、db:setupではなくdb:migrateを使ってマイグレーションをする場合、以下のコマンドでDBのセットアップを行っていました。 このとき、db:migrateでコケて、マイグレーションファイルを修正後に再度上記のコマンドを叩くと以下のように、ActiveRecord::NoEnvironmentInSchemaErrorが発生します。 rake aborted! ActiveRecord::NoEnvironmentInSchemaError: Environment data not found in the schema. To resolve this issue, run: bin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
