activerecord

Active RecordのTransactionブロック内で例外が投げられた場合、ActiveRecord::Rollback以外の例外はロールバックの後に再度投げられます。

したがって、処理失敗で例外を投げるメソッド（save!等）を使えば、基本的にその例外はロールバックの後Transactionブロックの外へ伝播します。 これをキャッチしなければ、RailsはHTTPのエラーレスポンスをブラウザ等のクライアントに返します。 つまり、「処理に失敗したら、ロールバックして、あとの処理は切り上げて、エラーレスポンスを返す」という挙動は簡単に実装できます。

一方で、「ロールバック後に例外を出さずに処理を継続する」場合には、ActiveRecord::Rollbackを活用できます。 以下は、Transactionの成否でリダイレクト先を変えるコード例です。

completed = false

ActiveRecord::Base.transaction do
  unless obj1.save && obj2.save
    raise ActiveRecord::Rollback
  end
  completed = true
end

if completed
  redirect_to completed_path
else
  redirect_to uncompleted_path
end

こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。

一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。

したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。

RailsのActive Recordには、scopeやdefault_scopeという機能があり、SQLクエリの条件を指定してあらかじめ付けておくことが可能です。

unscopeやunscopedは、これらのscope系で付けた条件を外すことが出来ます。
ただ、注意点として、scope系以外で付けた条件も外してしまいます。

以下に例を示します。

irb(main):001:0> puts User.where(id: 1).all.to_sql
SELECT "users".* FROM "users" WHERE "users"."id" = 1
=> nil
irb(main):002:0> puts User.where(id: 1).unscope(:where).all.to_sql
SELECT "users".* FROM "users"
=> nil
irb(main):003:0> puts User.where(id: 1).unscoped.all.to_sql
SELECT "users".* FROM "users"
=> nil

unscopeやunscopedが、直前のwhere句で指定した条件を外していることが確認できます。

確認した環境

• Rails 7.0.4

参考

• Railsガイド：Active Record クエリインターフェイス：9 条件を上書きする