サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめに 2024年1月にリテール(ネットショップ・レジ)部門からサービス(予約)部門に異動になった @ucks です。 異動してからはスマートリストという機能の開発を行っていて、5月6日に無事リリースできたのと、開発途中で障害に至ってしまった部分があるので、裏側を少し紹介しようかなと思います。 はじめに スマートリストとは スマートリストの設計 検索の仕様変更 高負荷時のハンドリング そして障害へ 見逃した点DBの実行計画確認時の見逃し 動作確認時の漏れ 監視先の漏れ ログの損失 おわりに スマートリストとは スマートリストの開発についての話を行う前に、まずはスマートリストについて簡単に説明しておきます。 スマートリストとは、特定の条件の顧客をラベリングする機能です。 早い話、最終予約日がいつ、予約回数が何回以上等の顧客の検索条件を保存しておいて、閲覧時にラベリングして、視認しやすくし
はじめに いよいよダットのターンです！たまにはRailsについて書かずHTMLかJavascriptばかりの記事を投稿したので今回はRailsのメソッドについて説明させていただきます。 開発者としてはこれらのメソッドを触ったことがあるはずですね。風通はこの三つの中に勝手に選んでどっちでも使って無事で計算されるので大丈夫と思いましたが、実はそうでしょうか？実際は場合によって返った結果も変わって実行する時間も異なる可能性があります。さっそくですが、始めましょう！ 概要 この記事はこれらのメソッドがRubyに使われる時を気にしないでActiveRecordに使用する時だけ中心してください。結局、アソシエーションの中に幾つのレコードがあるか教えてくれますが、内部の処理がちょっと違います。 例えば、このモーデルとリレーションがあります。
こんにちは！kossyです！ さて、今回はRailsのdependentオプションに指定できる、 restrict_with_error と restrict_with_exception はなにが違うのかについて、 ブログに残してみたいと思います。 環境Ruby 2.6.3Rails 6.0.3MacOS Catalina そもそもdependentオプションとは？ まずはドキュメントを読んでみましょう。 Controls what happens to the associated objects when their owner is destroyed: そのレコードが破棄されたときに、関連付けられたオブジェクトに何が起こるかを制御します。 出典: https://edgeguides.rubyonrails.org/association_basics.html#optio
プレーヤーがいないチーム C も一覧に表示されているのがポイントです。 以上の設定が、「結合先のプレーヤーテーブルにおいて論理削除されていないという条件をつけたいけど、チームのレコードは全部欲しい」という状況になっているのがお分かりいただけるでしょうか。 どうクエリメソッドを書けばよいか？ まずパッと思いつくもの 例えばこんなのはどうでしょうかね。 Team.eager_load(:players).where(players: {deleted: false}) すると以下のようなSQLが発行されます。 SELECT "teams"."id" AS t0_r0, "teams"."name" AS t0_r1, "teams"."created_at" AS t0_r2, "teams"."updated_at" AS t0_r3, "players"."id" AS t1_r0, "p
ActiveRecord::Base を継承したクラスをモデルとして作成すると、Rails はそのクラス名に対応したデータベースのテーブルを自動的に探そうとします。対応するデータベースのテーブルを用意しない場合は、self.abstract_class = true を書く必要があります。ActiveRecord::Base を継承したクラスを作成し、さらにそのクラスを継承させたい場合に self.abstract_class = true が書かれるようです。 実際にRails 5.0.1 にて検証しました。例えば、app/models 以下に ActiveRecord::Base を継承したクラス Animal を作ります。そしてクラス Animal を継承したクラス Dog を作ります。そしてデータベースには dogs というテーブルを作成します。 app/models/anima
![[Rails] self.abstract_class = true の意味と挙動](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f8d71ff5111e05619a10d29bb40d7aebaa75c8fbc%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fs0.wp.com%252Fi%252Fblank.jpg&f=jpg&w=240)
この時、例えば既に保存されているレコードに関して姓と名の間に半角スペースが必要だったのでレコード1~3を更新したいすると次のように書きたくなります。Employee.upsert_all( [ { id: 1, name: '野比 のび太' }, { id: 2, name: '剛田 武' }, { id: 3, name: '骨川 スネ夫' } ] ) が、この場合だと ActiveRecord::NotNullViolation:Mysql2::Error が発生してしまいます 理由はレコードが新規追加だったケースの時に問題があるSQLになってしまうからです。 新規追加だったケースの時に問題がある理由 上記のupsert_allを実行したときのSQLは次のようになります INSERT INTO `sample_database`.`employees`(`id`,`name`) V
class User < ApplicationRecord after_save { raise ActiveRecord::Rollback } end # consoleの中 ActiveRecord::Base.transaction do user = User.first # => User { name: "hoge" } user.update!(name: "new hoge") end 上記のコードではUserモデルのインスタンスを保存しています。callbacksはrailsがtransactionを作りその中で実行されるので、consoleで作ったtransactionにネストする形で新しいtransactionが始まり、after_saveの処理が実行されます。そしてこの場合、rollbackされずにuserのnameは"new hoge"に更新されてしまいます。
ネストしたトランザクションでのロールバック① (ActiveRecord::Rollback) まずはネストしたトランザクションでActiveRecord::Rollbackする場合を考えます。 Active::Record::RollbackはActiveRecord::ActiveRecordErrorを継承していて、またさらにこれはStandardErrorを継承しています。 エラークラスなのでraiseを使って以下のように使います。 class BooksController < ActionController::Base defcreate Book.transaction do book = Book.new(params[:book]) book.save! if today_is_friday? raise ActiveRecord::Rollback end end
migration の中で model を触ったら必ず reset_column_information する 治安の悪いRails アプリケーションでは、migrate 中に model の不整合で怒られることがあります。 class AddAgeToUsers < ActiveRecord::Migration[5.1] def up p User.first # 1 add_column :users, :age, :integer # 2 User.create(name: "Taro", age: 16) # 3 end end 1 で User model を触ってしまっているので add_column 前のDB の状態がキャッシュされて 2 で追加した add_column は別にキャッシュをリセットしないので 3 でActiveModel::UnknownAttrib
SmartHRでは開発にRuby onRailsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
[4] pry(main)> Kantai.find(1) Kantai Load (0.4ms) SELECT `kantais`.* FROM `kantais` WHERE `kantais`.`id` = 1 LIMIT 1 ActiveRecord::SubclassNotFound: The single-table inheritance mechanism failed to locate the subclass: '戦艦'. Thiserror is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this column if you didn't intendit to be used for stori
rails_6_1_new_features.mdRails 6.1で新しく入る機能について @willnet 最近のRailsリリース日 6.0.0 (2019/08/06) 5.2.0 (2018/04/09) 5.1.0 (2017/04/27) 5.0.0 (2016/06/30) だいたい1年くらいでマイナー、メジャーバージョンが上がるRailsConf(毎年だいたい4末くらいに開催)がターゲットになっていそう ではそろそろ6.1.0でるの？というとまだっぽい雰囲気を感じる https://github.com/rails/rails/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.1.0 一応6.1.beta1用のブログエントリの準備用PRはある(けどいまアクティブではない) Add post about 6.1.beta1 release
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
