DEV Community: Masataka Pocke Kuwabara

ActiveRecord::Originator, a RubyGem indicating the origin of the SQL

Masataka Pocke Kuwabara — Wed, 13 Mar 2024 15:28:44 +0000

This article is translated from a Japanese article written by me.

Hello, I'm Pocke.

Today, I created a gem called activerecord-originator, and I'd like to introduce it to you.

pocke / activerecord-originator

A RubyGem adding SQL comments to indicate the origin of the SQL

ActiveRecord::Originator

Add SQL comments to indicate the origin of the SQL.

This gem adds SQL comments indicating the origin of the part of the query. This is useful for debugging large queries.

Rails tells us where the SQL is executed, but it doesn't tell us where the SQL is constructed This gem lets you know where the SQL is constructed! For example:

Article Load (0.1ms)  SELECT "articles".* FROM "articles" WHERE "articles"."status" = ? /* app/models/article.rb:3:in `published' */
 AND "articles"."category_id" = ? /* app/controllers/articles_controller.rb:3:in `index' */
 ORDER BY "articles"."created_at" DESC /* app/models/article.rb:4:in `order_by_latest' */

You can see where .where and .order methods are called without reading the source code. It is helpful if the query builder is complex.

Installation

Install the gem and add to…

View on GitHub

What is this?

This gem inserts comments into each part of the SQL queried by Active Record, indicating where it was constructed.

To understand, it's faster to see an example. The following log is an example of a query executed in ArticlesController#index.

Article Load (0.1ms)  SELECT "articles".* FROM "articles" WHERE "articles"."status" = ? /* app/models/article.rb:3:in `published' */
 AND "articles"."category_id" = ? /* app/controllers/articles_controller.rb:3:in `index' */
 ORDER BY "articles"."created_at" DESC /* app/models/article.rb:4:in `order_by_latest' */

This gem adds the comments enclosed in /* ... */. From this, you can see that articles'.' status" = ? originates from the published method on line 3 of article.rb, that category_id is filtered in the controller, and where the scope that defines the ORDER BY is located.

Motivation

The simple example I mentioned earlier probably doesn't tell you this gem's advantage.

However, as SQL assembly becomes more complex, this gem will prove its true value. It's common for the location where a query is executed and the location where it's constructed to be far apart, such as when defining scopes. Moreover, when creating classes to construct queries for complex searches, searching within those classes can be quite a task.
With this gem, you can pinpoint how the query was constructed, making debugging easier.

It can also be useful for debugging default_scope because it is difficult to understand where they were applied. ¹

Usage

Run the following command to install the activerecord-originator gem.

$ bundle add activerecord-originator

That's all for the setup. Just by installing the gem, comments will be added to the queries.

Alternative Solutions

Similar gems include marginalia and activerecord-cause. Also, from Rails 7, a similar feature to marginalia has been standardly equipped in Rails.

The major difference between these traditional features and activerecord-originator is the granularity of comments (or logs). With traditional features, comments are output on a per-query basis. It's very convenient to know where that query was executed, but you couldn't get more detailed information.

activerecord-originator outputs comments for each element of SQL, conveying more detailed information. Information that was previously unknown becomes clear, increasing the information available for debugging.

The activerecord-originator is not intended to replace traditional features but is used in conjunction with them.

Caution

There are two things to be aware of when using activerecord-originator. One is the use of Active Record's internal API, and the other is performance.

Active Record Internal API

This gem strongly depends on Arel, which is an internal API of Active Record. Therefore, it may easily break with future Rails updates.
For example, it could break due to major internal refactoring.

It may also not work well with older versions of Rails. Although I have confirmed that the tests pass for Active Record v6.0 with some exceptions, and all tests pass for v6.1, there is no guarantee that older versions will continue to be supported.

Since it's a gem that can be easily installed and uninstalled, it's good to think that you might need to remove it from the Gemfile when updating Rails.

Performance

Since processing to output comments is performed every time a query is constructed, it is expected to incur a considerable cost.
Therefore, enabling it in a production environment could affect performance.

However, I haven't done any benchmarking or anything yet, so I don't know how much impact it will actually have.
If you measure the actual impact, I would be happy if you could let me know.

Implementation

Finally, I'll briefly introduce the implementation.

First, this gem prepends the ActiveRecord::Originator::ArelNodeExtension module to all descendant classes of Arel::Nodes::Node (I'll post the entire text below because it's short).
https://github.com/pocke/activerecord-originator/blob/v0.1.0/lib/activerecord/originator/arel_node_extension.rb

module ActiveRecord
  module Originator
    module ArelNodeExtension
      def initialize(...)
        __skip__ = super
        @ar_originator_backtrace = caller
      end

      attr_reader :ar_originator_backtrace
    end
  end
end

With this module, all nodes record their creation location (== the location where methods like where were called).

Another module, ActiveRecord::Originator::ArelVisitorExtension, is prepended to the Arel::Visitors::ToSql class.
https://github.com/pocke/activerecord-originator/blob/v0.1.0/lib/activerecord/originator/arel_visitor_extension.rb

The ToSql class traverses the Arel AST to generate SQL strings. The ArelVisitorExtension module overrides the methods corresponding to each node class in the ToSql class, inserting comments based on the location information recorded by ArelNodeExtension.

These two modules are the core of the implementation. The implementation itself is not very difficult, but it has become heavily dependent on Rails' internal API.

This was an introduction to the activerecord-originator gem, which makes SQL executed more debuggable. I would be happy if you could try it out.

And another module, ActiveRecord::Originator::ArelVisitorExtension, is prepended to the Arel::Visitors::ToSql class.

[https://github.com/pocke/activerecord-originator/blob/v0.1.0/lib/activerecord/originator/arel_visitor_extension.rb]

The ToSql class is a class that traverses the Arel AST to generate SQL strings. The ArelVisitorExtension module overrides the methods corresponding to each node in the ToSql class, inserting comments based on the location information recorded by ArelNodeExtension.

These two modules are the core of the implementation.
The implementation itself is not very difficult, but it has become heavily dependent on Rails' internal API.

This was an introduction to the activerecord-originator gem, which makes SQL executed more debuggable. I would be happy if you could try it out.

The idea for this gem came to me when I saw someone struggling to identify where a condition defined by default_scope was coming from, as it was not clear. ↩

RBS introduced manifest.yaml

Masataka Pocke Kuwabara — Sun, 26 Dec 2021 05:03:26 +0000

RBS introduced manifest.yaml
RBS v2.0.0, for Ruby 3.1, has been released!
RBS v2 contains many my patches. I recently work for rbs collection feature especially. In short, rbs collection is "Bundler" for RBS. It installs, updates and loads gems' RBSs for rbs, steep and typeprof commands.

In this article, I describe a feature of rbs collection, it is manifest.yaml.
manifest.yaml is a file to describe standard libraries dependencies for RBS.

Motivation

rbs collection detects the dependencies from Gemfile.lock.
For example, if your Gemfile has an entry, gem 'rails', rbs collection finds dependencies gems, such as activesupport, railties, nokogiri and so on, from Gemfile.lock. Then it installs RBSs from ruby/gem_rbs_collection repository.

It almost works well, but it has a problem. Gemfile.lock doesn't have standard libraries entries often.
For example, rails gem depends on pathname stdlib, but the dependency doesn't appear in Gemfile.lock. So rbs collection couldn't find pathname dependency from Gemfile.lock, then the user sees Could not find Pathname (RBS::NoTypeFoundError).

manifest.yaml solves this problem.

What is `manifest.yaml`

manifest.yaml is a file to describe standard libraries dependencies for RBS.

The following is the manifest.yaml of activesupport gem.

dependencies:
  - name: monitor
  - name: date
  - name: singleton
  - name: logger
  - name: mutex_m
  - name: time
  - name: pathname

https://github.com/ruby/gem_rbs_collection/blob/ce6664cec7387b4f5b52d01b80d26e9a9f9ad79c/gems/activesupport/6.0/manifest.yaml

It's simple. If Gemfile.lock has activesupport entry, rbs collection finds the stdlib dependencies from the manifest.yaml.

Who writes `manifest.yaml`

If you are an application developer, you don't need to write manifest.yaml. You can add a dependency entry to rbs_collection.yaml if your application depends on standard library.

If you are a gem author and the gem contains RBS in sig/ directory, you can put sig/manifest.yaml.

If you'd like to contribute ruby/gem_rbs_collection, you can put gems/GEM_NAME/VERSION/manifest.yaml. Follow the activesupport example.

Future work

Currently rbs collection resolves stdlib dependencies, but rbs -r LIB option doesn't resolve them unfortunately.
For instance, logger depends on monitor, but rbs -r logger doesn't load monitor.

I'll work to fix this problem soon.

By the way, I'll change my job next year to focus on developing RBS. I'll work for both Rails apps and RBS as my job to make RBS production-ready for real Rails applications!

The future of rbs collection

Masataka Pocke Kuwabara — Tue, 28 Sep 2021 15:48:21 +0000

Recently I discussed the future of rbs collection in ruby-jp, the Japanese online Ruby community. The discussion was exciting, so I'd like to share it.

By the way, if you don't know rbs collection, see https://dev.to/pocke/rbs-collection-was-released-4nmm . This article introduces rbs collection with a motivating example.

TL;DR

I'm planning the following idea to scale rbs collection to grown ruby/gem_rbs_collection.

rbs collection will migrate to use RubyGems' scoped packages in a few years, like @types/*of TypeScript.
But RubyGems doesn't have the feature, so we need to develop it.

Background

@ybiquitous asked me did I consider providing ruby/gem_rbs_collection's RBS as a gem, like @types/** of TypeScript. I had the idea but I didn't adopt it for the first release of rbs collection. And I realized I didn't describe the reason publicly. I summarized the answer to the question in this article.

Current Implementation

Currently, rbs collection downloads RBSs with git clone from ruby/gem_rbs_collection GitHub repository.

It works well for now, but probably it will introduce many problems in a few years because the repository will grow as DefinitelyTyped.

It will be slow!
- As you know, cloning a large repository is slow.
- The repository will have many gem's RBSs.
It will be expensive for GitHub's server.
- CocoaPods used (or still uses?) shallow clone, and it was too expensive.
  - https://github.com/CocoaPods/CocoaPods/issues/5016
  - https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935

Partial clone reduces the impact, but it just procrastinates the problems.

Why I chose `git clone`?

git clone is slow, but it is the simplest way.

At first I created a PoC with GitHub API v4 (GraphQL) because it could keep less API calls. However it was not a good idea. GitHub API requires an API token, so the user needs to prepare a Personal Access Token to use it for the local environment and CI.
GitHub API v4 has another problem; It truncates large file contents. Therefore I needed combining GitHub API v4 and another API.

I think git clone is a good compromise for now. It is the same phase of tsd or typings of TypeScript. We needed a simple RBS manager now as you can see from the previous article.

However git clone will introduce performance issues. I'll describe a solution idea in the next section.

Solution Idea

The solution idea is using RubyGems' scoped packages. It is the same way of @types/* of TypeScript.

For example, imagine a Gemfile:

# Gemfile

source "https://rubygems.org"

# I use the following gems
gem "rails"
gem "sidekiq"
gem "parallel"

# So, I need the following RBSs!
gem "@types/rails"
gem "@types/sidekiq"
gem "@types/parallel"

Put the Gemfile, then execute bundle install. That's all! Steep and so on load RBSs from @types/* gems.

It looks useful, but I need to solve many things to realize the idea.

First of all, we need to implement the scoped packages feature to RubyGems! Unfortunately RubyGems doesn't have the feature😭 @hsbt told a related issue to me.

Just off the top of my head I can imagine we need many tasks to implement it, adding organization, adding UI of rubygems.org, the authentication and authorization, updating gemspec/Gemfile.lock/installed package's path, and so on.

We still have another issue; It needs automatically published @types/* packages.
It is easier than implementing scoped packages, of cause. I guess we just need to set-up a workflow of GItHub Actions.

Nothing has been decided yet, but I think it is the best way. I'll investigate it.

Another idea

@znz told another idea; Using RubyGems' source instead of scoped packages. For example:

# Gemfile

source "https://rubygems.org"

# It is the same
gem "rails"
gem "sidekiq"
gem "parallel"

source "https://rbs.rubygems.org" do
  gem "rbs-rails"
  gem "rbs-sidekiq"
  gem "rbs-parallel"
end

Realizing the solution is easier than the scoped packages solution. It doesn't need to modify RubyGems, we can realize it with existing assets!

However this solution has problems:

We need a server to host rbs.rubygems.org.
- I don't want to maintain the server.
The package name can conflict with a gem from rubygems.org.
- If both rubygems.org and rbs.rubygems.org have rbs-rails gem, user cannot use both gems together.
- We can solve the problem with more unique prefix like rbs-types-*, but I think it is not smart.

I think source is not the best way, but maybe we can use the solution as a temporary solution.

Conclusion

git clone will be slow with grown ruby/gem_rbs_collection. Therefore I'm planning to migrate rbs collection to use RubyGems' scoped package, but it has difficulty.

I think scoped package is the best solution to manage third party RBSs in the long term. I work on improving RBS management. 🚀💎

rbs collection was released!

Masataka Pocke Kuwabara — Fri, 17 Sep 2021 17:49:03 +0000

Recently we released RBS v1.6 with rbs collection feature which is "Bundler" for RBS! The feature is experimental now, and it will be GA in RBS v2 for Ruby 3.1. Now you can use it with gem install rbs if you use Ruby 2.6+!

I'm an RBS maintainer and I designed and implemented the feature, so I'll describe rbs collection feature in this article.

By the way, I made a presentation on Sep. 10 at RubyKaigi Takeout 2021 and explained rbs collection in the talk. This article is based on the talk. See https://github.com/pocke/rubykaigi-2021 for more details (unfortunately I spoke in Japanese but it has English slides and subtitles).

What is RBS

First of all, I introduce RBS.

RBS is a language to describe Ruby types. It is similar to .d.ts of TypeScript or header files of C-language.
The syntax is similar to Ruby.

The following code is a simple RBS example:

class Blog
  attr_reader name: String

  def initialize: (String name) -> void

  def each_article: () { (Article) -> void } -> self # For blog.each_article { |article| ... }
                  | () -> Enumerator[Article, self]  # For blog.each_article.map { |article| ... }
end

class Article
  attr_reader title: String
  attr_reader content: String

  def initialize: (String title, String, content) -> void

  def published_at: () -> Time
end

ruby/gem_rbs_collection

I need to describe another topic before describing rbs collection. It is ruby/gem_rbs_collection GitHub repository.

The repository stores third-party gems' RBSs, like DefinitelyTyped.

rbs collection feature integrates this repository and tools use RBS, such as rbs command, Steep, and TypeProf.

rbs collection

It's the main topic of this article💪

rbs collection manages third-party RBSs, for example, installing, updating, and loading.

The first section describes a motivating example of rbs collection.
Before rbs collection, managing third-party RBSs is not efficient.

The second section describes how rbs collection solves the problem.

The last section describes known issues of rbs collection.
The feature still has some known issues for now, and I'll solve the issues until RBS v2.

Motivating example

In this section, I describe how to set up third-party RBSs for a Rails app without rbs collection as the motivating example.

How to set up

First, download ruby/gem_rbs_collection repository as a git submodule.

$ git submodule add https://github.com/ruby/gem_rbs_collection.git gem_rbs_collection

Then rbs command is available but it needs many options. For example, the following command is necessary to validate RBSs.

# too many options ¯\_(ツ)_/¯
$ rbs -rlogger -rpathname -rmutex_m -rdate -rmonitor \
      -rsingleton -rtsort -rtime -rrack \
      -ractivesupport -ractionpack -ractivejob \
      -ractivemodel -ractionview -ractiverecord \
      -rrailties \
      --repo=gem_rbs_collection validate

# TypeProf also needs the same options.
$ typeprof -rlogger -rpathname -rmutex_m -rdate -rmonitor \
           -rsingleton -rtsort -rtime -rrack \
           -ractivesupport -ractionpack -ractivejob \
           -ractivemodel -ractionview -ractiverecord \
           -rrailties \
           --repo=gem_rbs_collection validate

-r options specify library names you want to load, and --repo option specifies the repository path which is the git submodule.

And Steep needs a different configuration to load the same RBSs.

# Steepfile

target :app do
  # Specify a directory that contains target Ruby files to type check.
  check 'app'
  # Specify the git submoduled directory
  repo_path "gem_rbs_collection"
  # Specify the all library names to load.
  library 'pathname', 'logger',  'mutex_m', 'date',
          'monitor', 'singleton', 'tsort', 'time', 'rack',
          'activesupport', 'actionpack', 'activejob',
          'activemodel', 'actionview', 'activerecord',
          'railties'
end

Many options are required because rbs, TypeProf, and Steep don't know which libraries are required.

Motivations

As you can see, managing third-party RBSs has problems. I explain three problems.

First, we need to resolve dependencies by hand. In the above examples, human resolved "my app depends on Active Support, then Active Support depends on Logger, and ...". It is too hard for humans 😂

Second, we need git submodule or copying RBSs to download third-party RBSs. It's too primitive. If you want to use different revisions RBSs, you can't use submodule but copying RBSs looks a hell.
For example, you want to use gem X RBS with revision R, but want to use gem Y RBS with revision R', git submodule doesn't work.

Third, we need to use different ways between RBS, Steep, and TypeProf to load RBSs. rbs command and TypeProf need to specify library names as command-line options, but Steep needs to specify them in Steepfile. It is not a single source so it is hard to maintain.

How `rbs collection` solves the problem

rbs collection automatically resolves dependencies, downloads RBSs, and loads RBSs from the single source. It means rbs collection sovles these problems!

To use rbs collection, you need to install rbs gem v1.6+. Then initialize the configuration file with rbs collection init command.

# Install rbs gem v1.6+
$ gem install rbs

# Initialize the config file
$ rbs collection init
warning: rbs collection is experimental, and the behavior may change until RBS v2.0
created: rbs_collection.yaml

After that, edit the generated configuration file, rbs_collection.yaml. The full content is the following:
Note that I'll describe why you need to edit it in the "Known Issues" section.

# Download sources
sources:
  - name: ruby/gem_rbs_collection
    remote: https://github.com/ruby/gem_rbs_collection.git
    revision: main
    repo_dir: gems

# A directory to install the downloaded RBSs
path: .gem_rbs_collection

gems:
  # Skip loading rbs gem's RBS.
  # It's unnecessary if you don't use rbs as a library.
  - name: rbs
    ignore: true
  # 👮👮👮 Add the following lines
  - name: pathname
  - name: logger
  - name: mutex_m
  - name: date
  - name: monitor
  - name: singleton
  - name: tsort
  - name: time
  - name: set

Then, execute rbs collection install command.

# rbs collection uses Gemfile.lock to resolve dependency,
# so execute `bundle install` before that to generate Gemfile.lock.
$ bundle install

# Install RBSs from ruby/gem_rbs_collection repo
$ rbs collection install

Finally, the CLI tools are available!

You can use rbs and TypeProf commands without options.

$ rbs validate
$ typeprof target.rb

You can use Steep with a few configurations.

# Steepfile

target :app do
  # Specify a directory that contains target Ruby files to type check.
  check 'app'
end

Note that the rbs collection integrations with Steep and TypeProf have not been released yet now (2021-09-18). You need to install them from GitHub if you want to try them for now.
Steep integration was implemented in https://github.com/soutaro/steep/pull/420 but not yet released.
TypeProf integration was implemented in https://github.com/ruby/typeprof/pull/53 but not yet merged.

The mechanism of `rbs collection install`

rbs collection install command works with the following steps.

Generating rbs_collection.lock.yaml
1. Resolve the dependencies with Gemfile.lock.
2. Write the gems to the lockfile, rbs_collection.lock.yaml.
Installing RBSs
1. Copy RBSs from ruby/gem_rbs_collection with the lockfile.

Then, rbs, steep and typeprof commands load the installed RBSs.

Known Issues

Unfortunately rbs collection has known issues.

Resolving Standard Libraries' Dependencies

rbs collection doesn't resolve dependencies of most standard libraries. For example, logger, pathname, etc.

In many cases, standard libraries do not appear in Gemfile.lock so rbs collection can't find them from Gemfile.lock.
We can do require stdlibs even if the stdlib is not included in gemspec or Gemfile. So most gems don't have explicit dependencies to stdlibs. For example, rails gem depends on many stdlibs such as pathname, but the gemspec doesn't include pathname.

I'll fix the problem by introducing a configuration file for RBS, such as one called manifest.yaml. The file will contain all stdlib dependency names.
For example, if foo gem depends on pathname and logger, the manifest.yaml will be the following.

# ruby/gem_rbs_collection/gems/foo/1.0/manifest.yaml

depends_on:
  - name: pathname
  - name: logger

Other issues

rbs collection has other known issues. See https://github.com/ruby/rbs/pull/589 and https://github.com/ruby/rbs/issues/794 for more information.

Conclusion

I introduced rbs collection, which is the "Bundler" for RBS.
You can easily manage third party RBSs with the command.

I hope you will give it a try. Feel free to open issues if you have any problems!
Thank you for reading <3

Rails 7 will introduce invert_where method, but it's dangerous

Masataka Pocke Kuwabara — Mon, 03 May 2021 03:26:25 +0000

NOTE: This article based on today's latest commit of the main branch.

TL;DR

invert_where inverts all where conditions.
It may invert unexpected conditions, so it's dangerous.

What is `invert_where`?

ActiveRecord::QueryMethods::WhereChain#invert_where will be introduced since Rails 7. It inverts where conditions.

For example: (From the CHANGELOG

class User
  scope :active, -> { where(accepted: true, locked: false) }
end

User.active
# ... WHERE `accepted` = 1 AND `locked` = 0

User.active.invert_where
# ... WHERE NOT (`accepted` = 1 AND `locked` = 0)

It is implemented in #40249.

Why `invert_where` is dangerous

The risk becomes clear with several where. For example:

puts Post.where(a: 'a').where(b: 'b').invert_where.to_sql

In this case, invert_where inverts both of the where conditions. So it prints the following results.

SELECT "posts".* FROM "posts" WHERE NOT ("posts"."a" = 'a' AND "posts"."b" = 'b')

As you can see, the whole of the conditions is inverted with NOT.

This behavior will be bugs with the following three examples.

The examples work with the following set-up code.

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  gem "activerecord", github: 'rails/rails', ref: '11a3348c2d58f448b8f1dea4f4dbb8cd5bb95a0e'
  gem "activemodel", github: 'rails/rails', ref: '11a3348c2d58f448b8f1dea4f4dbb8cd5bb95a0e'
  gem "activesupport", github: 'rails/rails', ref: '11a3348c2d58f448b8f1dea4f4dbb8cd5bb95a0e'
  gem "sqlite3"
end

require "active_record"

ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")

ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
    t.string :role
    t.datetime :disabled_at
  end
end

1. Using `invert_where` in a scope definition

If a scope definition includes invert_where, the invert_where affects outside of the scope.
For example:

class User < ActiveRecord::Base
  scope :alive, -> { where(disabled_at: nil) }
  scope :disabled, -> { alive.invert_where }

  scope :admin, -> { where(role: 'admin') }
end

puts User.admin.disabled.to_sql
# => SELECT "users".* FROM "users" WHERE NOT ("users"."role" = 'admin' AND "users"."disabled_at" IS NULL)

In this case, User.admin.disabled.to_sql expects returning disabled admin users. But actually, it returns not-admin users and disabled users. It means .admin scope is inverted unexpectedly.

2. When the relation starts in a different place with `invert_where` call

It is similar to the first problem. In this case, invert_whre is not hidden in a scope definition, but the relation and invert_where are in different places.
This problem is well described in a comment in the pull request, which implements invert_where, so I quote the comment.

Imagine, somewhere within the request flow, perhaps automatically scoped by Pundit,
current_user = User.first
posts = Post.where(author: current_user)
And then later on in a controller…
published_posts = posts.where(published: true)
draft_posts = published_posts.invert_where
The draft_posts variable is now all draft posts NOT by the current user. Putting the above logic in published and unpublished scopes, respectively, would be make this issue even more confusing to debug if it did occur.

3. With `default_scope`

Combination of invert_where and default_scope is surprising.

class User < ActiveRecord::Base
  default_scope -> { where(disabled_at: nil) }

  scope :admin, -> { where(role: 'admin') }
end

puts User.admin.invert_where.to_sql
# => SELECT "users".* FROM "users" WHERE NOT ("users"."disabled_at" IS NULL AND "users"."role" = 'admin')

In this case, default_scope is used to ignore disabled users always. And User.admin.invert_where expects returning "available non-admin users".

But actually it displays an unexpected SQL. The query means "disabled, or not-admin users". Because invert_where also inverts default_scope.

I think default_scope is a bad practice. The combination with invert_where makes it worse.

Conclusion

invert_where is dangerous, so you need to be careful if you want to use it.

If you pay close attention to the method, you can avoid the problems. But human makes mistakes, and it is not easy for beginners.
So I proposed a RuboCop rule for invert_where to rubocop-rails project.

https://github.com/rubocop/rubocop-rails/issues/470

But I think it still a dangerous method even if the cop is implemented. So I'm wondering if it should be reverted until releasing Rails 7.

This article is self-translated from a Japanese article

DEV Community: Masataka Pocke Kuwabara

ActiveRecord::Originator, a RubyGem indicating the origin of the SQL

pocke / activerecord-originator

A RubyGem adding SQL comments to indicate the origin of the SQL

ActiveRecord::Originator

Installation

What is this?

Motivation

Usage

Alternative Solutions

Caution

Active Record Internal API

Performance

Implementation

RBS introduced manifest.yaml

Motivation

What is manifest.yaml

Who writes manifest.yaml

Future work

The future of rbs collection

TL;DR

Background

Current Implementation

Why I chose git clone?

Solution Idea

Another idea

Conclusion

rbs collection was released!

What is RBS

ruby/gem_rbs_collection

rbs collection

Motivating example

How to set up

Motivations

How rbs collection solves the problem

The mechanism of rbs collection install

Known Issues

Resolving Standard Libraries' Dependencies

Other issues

Conclusion

Rails 7 will introduce invert_where method, but it's dangerous

TL;DR

What is invert_where?

Why invert_where is dangerous

1. Using invert_where in a scope definition

2. When the relation starts in a different place with invert_where call

3. With default_scope

Conclusion

What is `manifest.yaml`

Who writes `manifest.yaml`

Why I chose `git clone`?

How `rbs collection` solves the problem

The mechanism of `rbs collection install`

What is `invert_where`?

Why `invert_where` is dangerous

1. Using `invert_where` in a scope definition

2. When the relation starts in a different place with `invert_where` call

3. With `default_scope`