unreliable 0.9.1 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 9b11225a3c1dad62d2a283c3eb36fef7b69fda61815df13a860ce9c1970016eb
-  data.tar.gz: 1994dd9ea21ba01dc839c56cc08ca91742465dc9b850c0b6a5eebbc81c7558a2
+  metadata.gz: 17d0865e8524f14bc5d1ddc01106ccf63adb25f044a7ea3ca9109d44c6f31f3f
+  data.tar.gz: c3b5ff4213d9fb54bd3a48838ad0642c4a132e80715e45500ecf3c6884cd6f47
 SHA512:
-  metadata.gz: 145d5bbe8790fe4ee33bf4f0ea874350edf9655c2ebed35bfb3f18acb123d03efbe86c826dd0d9d4ca7ff12938c368e5cc4ebdc7afba224e0a8c12669a92e816
-  data.tar.gz: 2a3ca2dfa53cbf67a0f8a6b7128df829874409a698586c15d10746624a71a18eddc77914768ec5da361541aa54706bd1899f473aa1f6093ec839f689428b36ed
+  metadata.gz: 461eb8a9445d48f09ff0b6e89f097fba52685f55e93637c1e2c6bc582104af44d3e30d8c503f10e145f1a3ef052f9fdaf2b4c9cb2544f3e71080f87ea2d9854a
+  data.tar.gz: 892d721b2ff0b45430625c1feae890ce0dbdc194dcab3118f8d20251af0eb0ee2c2d45bc4550bfd5ddbff334524c42c67b2d642a53709efa9c289e27a866f956

data/CHANGELOG.md

@@ -1,3 +1,31 @@
+## Unreliable 1.0.0 (April 18, 2026) ##
+
+### Fixed
+
+* Fixed crash on Rails 7.2+ caused by removal of `Arel::Table.engine` — replaced with `lease_connection` helper.
+* `Config.disable` is now thread-safe — uses `Thread.current` instead of toggling a global flag, so parallel test runners don't interfere with each other.
+
+### Added
+
+* SQL Server support — queries get `ORDER BY NEWID()`; DISTINCT queries are skipped (same rationale as PostgreSQL).
+* Trilogy MySQL client support alongside `mysql2`.
+* Rails 7.2, 8.0, and 8.1 compatibility; upper version bound raised to `< 9.0`.
+* Ruby 3.4 and 4.0 added to the CI matrix.
+* Many new specs: eager loading, `first`/`last`, `limit`, `reorder`, `group`/`having`, `or` queries, `pluck`/`exists?`/aggregates, `find_each`, and thread safety.
+
+### Changed
+
+* Development dependencies moved from gemspec to Gemfile.
+* Suppressed C-extension deprecation warnings from sqlite3 1.3.x on Ruby 2.7 (#4).
+
+## Unreliable 0.10.0 (January 15, 2024) ##
+
+### Changed
+
+* Rails 5.0 and 5.1 compatibility removed due to bug in interaction with Arel 8. This is not a breaking change because it didn't work before. If you must run Rails < 5.2, do not use Unreliable.
+* PostgreSQL bug with SELECT DISTINCT fixed (#10).
+* Many tests added; CI dockerized; test suite runs against SQLite, PostgreSQL, and MySQL (#3).
+
 ## Unreliable 0.9.1 (November 21, 2022) ##
 
 ### Changed

data/Gemfile

@@ -3,3 +3,15 @@
 source "https://rubygems.org"
 
 gemspec
+
+gem "appraisal", "~> 2.4"
+gem "bundler", "~> 2.1"
+gem "combustion", "~> 1.5"
+gem "mysql2", "~> 0.5"
+gem "ostruct"
+gem "pg", "~> 1.5"
+gem "rake", "~> 13.0"
+gem "rspec", "~> 3.0"
+gem "sqlite3", (RUBY_VERSION >= "3.2") ? "~> 1.6.9" : "~> 1.5.4"
+gem "standard", "~> 1.17"
+gem "yamllint", "~> 0.0.9"

data/README.md

@@ -15,11 +15,11 @@ Add `unreliable` to your `Gemfile`'s `test` group:
 # Gemfile
 
 group :test do
-  gem "unreliable", "~> 0.1"
+  gem "unreliable", "~> 0.10"
 end
 ```
 
-The next time your test suite runs, it may emit new errors and failures. If so, great!
+And run `bundle install`. Then try running your test suite. If it emits new errors and failures, great!
 
 ## The problem with orders
 
@@ -27,17 +27,26 @@ Here's an [open secret](#references): **relational databases do not guarantee th
 
 If all your ActiveRecord ordering is already unambiguous, congratulations! `unreliable` will have no effect.
 
-But sometimes we think we specified an unambiguous order, but didn't. Maybe we ordered on timestamps, which are usually unique but sometimes not. And the test suite will stay silent as long as our database just happens to return the same order.
+But sometimes... we think we specified an unambiguous order, but we didn't. For example, maybe we ordered on timestamps, which are usually unique but sometimes not.
 
-If ambiguous ordering is fine for your app's purposes, but your tests rely on a specific order, that's a bug in your tests. Your tests are incorrectly failing -- rarely -- which can be confusing and annoying.
+The test suite will stay silent about that, as long as our database just happens to return the same order. That silence is a problem.
 
-Or, if your Rails code relies on that accidental ordering, that's a bug in your app. Your tests are passing when they should be failing.
+If ambiguous ordering is fine for your app's purposes, but your tests rely on a specific order, that's a **bug in your tests**. Your tests are incorrectly failing -- rarely -- which can be confusing and annoying.
+
+Or, if your Rails code relies on that accidental ordering, that's a **bug in your app**. Your tests are passing when they should be failing.
 
 In both cases, `unreliable` exposes the problem by making those tests fail most of the time.
 
 ## Fixing the new failures
 
-When `unreliable` turns up a new test failure, you fix it in one of two ways. Either relax your test so it stops relying on order, or tighten up your app to specify order rigorously. (In my company's app, it was about 50/50.)
+When `unreliable` turns up a new test failure, you fix it in one of two ways.
+
+Either:
+
+ * relax your test so it stops relying on order,
+ * or tighten up your app to specify order rigorously.
+
+In my company's app, it was about 50/50.
 
 ### Relax a test
 
@@ -45,7 +54,7 @@ Take a look at what your test is checking. If you're testing a method or an endp
 
 * Make your test accept all correct answers. For example, sort an array in the method's response before comparing.
 
-* Help your test suite focus on what you're testing. If your fixtures' "latest" element could change because they don't specify a timestamp, that might be a distraction that's not relevant to how your app works, so you could assign timestamps to the fixtures.
+* Help your test suite focus on what you're testing. If your fixtures' "latest" element could change because they don't specify a timestamp, that might be a distraction that's not relevant to how your app works, so you could assign unique timestamps to the fixtures.
 
 This makes your test suite more robust.
 
@@ -53,7 +62,9 @@ If your test suite is checking generated `.to_sql` against known-good SQL text,
 
 ### Tighten the app
 
-If your app should be returning results in a particular order, and now with `unreliable` it sometimes does not, your test is correct and your app is wrong. Specify order rigorously in your app.
+If your app should be returning results in a particular order, and now with `unreliable` it sometimes does not, your test is correct and your app is wrong.
+
+Specify order rigorously in your app.
 
 Maybe you're testing `Book.reverse_chron.first`, and you've defined that ordering this way:
 
@@ -75,19 +86,25 @@ Or, if `title` is not unique:
   scope :reverse_chron, -> { order(year_published: :desc, title: :desc, id: :desc) }
 ```
 
-The problem in this example is easy to see because many books are published each year. But this error can occur at any time granularity.
+This example's problem is easy to see because many books are published each year.
+
+But this error can occur at any granularity, in time or other data types.
 
 ## Requirements
 
-`unreliable` is tested to support Ruby 2.6 through 3.1, and Rails 5.0 through 7.0.
+`unreliable` is tested on every valid combination of:
 
-As of November 2022, this is all released versions of both that are currently supported, plus several older releases.
+ * sqlite, postgresql, mysql2, trilogy, and sqlserver adapters
+ * Ruby 2.6 through 4.0
+ * Rails 5.2 through 8.1
+
+SQL Server tests run in CI (x86\_64) only; the SQL Server 2022 Docker image has no arm64 variant and is unstable under QEMU on Apple Silicon.
 
 `unreliable` depends only on ActiveRecord and Railties. If you have a non-Rails app that uses ActiveRecord, you can still use it.
 
 ## Implementation
 
-`unreliable` does exactly nothing outside of test environments. There is intentionally no way to enable `unreliable` in production, and there never will be.
+`unreliable` does exactly nothing outside of test environments. There is intentionally no way to enable it in production, and there never will be.
 
 In a Rails test environment, `unreliable` patches ActiveRecord to append a final `ORDER BY` clause, when necessary, that returns results in a random order.
 
@@ -95,53 +112,51 @@ Because it's appended, the existing ordering is not affected unless it is ambigu
 
 With `unreliable` installed, every ActiveRecord relation invoked by the test suite will have any ambiguity replaced with randomness. Tests that rely on the ordering of two records will break half the time. Tests with three or more break most of the time.
 
-`unreliable` patches `ActiveRecord::QueryMethods#build_arel`, the point where an Arel is converted for use, to append an order to the existing order chain. (The patch is applied after ActiveRecord loads, using `ActiveSupport.on_load`, the standard interface since Rails 4.0.) It works with MySQL, Postgres, and SQLite.
+`unreliable` patches `ActiveRecord::Relation#build_order`, the point where ordering is assembled, to append a random-order term to the existing order chain. (The patch is applied after ActiveRecord loads, using `ActiveSupport.on_load`, the standard interface since Rails 4.0.) It works with MySQL, PostgreSQL, SQLite, and SQL Server.
+
+Patching `build_order` ensures that the `ORDER BY` applies to not just `SELECT` but e.g. `delete_all` and `update_all`. It also applies within subqueries.
 
-This means that the `ORDER BY` applies to not just `SELECT` but e.g. `delete_all` and `update_all`. It also applies within subqueries.
+The patch is only applied when `Rails.env.test?`, so it has zero effect on production. Just to be sure, the environment is also checked on every invocation, to make absolutely certain this code can run only in `test`.
 
-The patch is only applied when `Rails.env.test?`, and that boolean is also checked on every invocation, just to make certain it has no effect in any other environment.
+The gem has a large test suite that checks for correctness at several abstraction layers inside ActiveRecord. It ensures the correct SQL is generated and that it executes correctly.
 
 ### No dual-purpose environment please
 
-Your test environment is just for running your test suite. If you've overloaded the test environment to do any actual work, you'd be frustrated when `unreliable` slows it down and changes its behavior, so don't install it (yet).
+Your test environment is just for running your test suite. If you've overloaded the test environment to do any actual work, you'll be frustrated when `unreliable` slows it down and changes its behavior. Don't do that.
 
 ## Contributing
 
-Thoughts and suggestions are welcome. Please read the code of conduct, then create an issue or pull request on GitHub. If you just have questions, go ahead and open an issue, I'm pretty friendly.
+Thoughts and suggestions are welcome. Please read the code of conduct, then create an issue or pull request on GitHub. If you just have questions, please go ahead and open an issue!
 
 ### Run the gem's tests
 
-To test locally, against the different versions of ActiveRecord, use Ruby 2.7, the only version currently compatible with all the ActiveRecord versions supported. Install the required gems with:
-
-```
-gem install bundler
-bundle install
-bundle exec appraisal install
-```
+To test locally, see the hint at the top of `compose.yaml` to spin up docker containers.
 
-Run `unreliable`'s linter with:
+After you spin up the containers and open a shell in the app container, run `unreliable`'s linter with:
 
 ```
-bundle exec standardrb
+standardrb
 ```
 
-Then you can run `unreliable`'s tests with:
+Run its tests in separate passes:
 
 ```
-bundle exec appraisal rake
+RSPEC_ADAPTER=sqlite bundle exec rake
+RSPEC_ADAPTER=postgresql bundle exec rake
+RSPEC_ADAPTER=mysql2 bundle exec rake
+RSPEC_ADAPTER=trilogy bundle exec rake
+RSPEC_ADAPTER=sqlserver bundle exec rake
 ```
 
-Appraisal ensures the tests run against every compatible minor version of ActiveRecord.
-
-The GitHub CI workflow in `.github/` ensures those tests are also run against against every compatible minor version of Ruby. Your PR won't trigger my GitHub project's workflow, but you're welcome to run your own, or ask me to run mine manually.
+The SQL Server pass requires an x86\_64 host; the SQL Server 2022 Docker image does not run on Apple Silicon.
 
-Testing against ActiveRecord is done with [Combustion](https://github.com/pat/combustion), which stands up a local SQLite database and ActiveRecord-based models for it. This gives more reliable coverage than mocking unit tests within ActiveRecord itself, though I do some of that too.
+The GitHub CI workflow in `.github/` ensures those tests are also run against every compatible minor version of Ruby. Your PR won't trigger my GitHub project's workflow, but you're welcome to run your own, or ask me to run mine manually.
 
 ### Experiment
 
 If you'd like to see `unreliable` in action on a small but real Rails app locally, you can do this:
 
-1. In a directory next to your `unreliable` working directory, create a `.ruby-version` of `2.7.6` and a 2-line `Gemfile`: `source "https://rubygems.org"`, `gem "rails", "~> 7.0"`
+1. In a directory next to your `unreliable` working directory, create a `.ruby-version` of `2.7.8` and a 2-line `Gemfile`: `source "https://rubygems.org"`, `gem "rails", "~> 7.0"`
 2. `bundle install && bundle exec rails new . --force`
 3. `echo 'gem "unreliable", path: "../unreliable"' >> Gemfile`
 4. `bundle install && bundle exec rails generate model post title:string body:text`
@@ -166,8 +181,8 @@ The most common ambiguous ordering is an ORDER BY one column that is not unique,
 But there are other ways you can order a relation but still have your query be ambiguous:
 
 * ORDER BY multiple columns, but with no subset which is unique
-* ORDER BY a column with values that differ only by [character case](https://dev.mysql.com/doc/refman/8.0/en/sorting-rows.html)
-* ORDER BY values that are identical within the [prefix length limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_sort_length) examined for sorting
+* ORDER BY a column your [pre-Rails-6.1](https://guides.rubyonrails.org/6_1_release_notes.html#active-record-notable-changes) application thought was unique, but currently isn't, due to your non-UNIQUE database column's accent- or case-insensitive [collation](https://dev.mysql.com/doc/refman/8.0/en/charset-general.html)
+* ORDER BY values that are identical only within the [prefix length limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_sort_length) examined for sorting
 
 `unreliable` ensures correct testing because it appends a random order to each of these cases.
 
@@ -181,11 +196,11 @@ MySQL ([5.6](https://dev.mysql.com/doc/refman/5.6/en/limit-optimization.html), [
 
 > If multiple rows have identical values in the `ORDER BY` columns, the server is free to return those rows in any order, and may do so differently depending on the overall execution plan. In other words, the sort order of those rows is nondeterministic with respect to the nonordered columns.
 
-Postgres ([12](https://www.postgresql.org/docs/12/sql-select.html#SQL-ORDERBY), [13](https://www.postgresql.org/docs/13/sql-select.html#SQL-ORDERBY), [14](https://www.postgresql.org/docs/14/sql-select.html#SQL-ORDERBY)):
+Postgres ([13](https://www.postgresql.org/docs/13/sql-select.html#SQL-ORDERBY), [14](https://www.postgresql.org/docs/14/sql-select.html#SQL-ORDERBY), [15](https://www.postgresql.org/docs/15/sql-select.html#SQL-ORDERBY), [16](https://www.postgresql.org/docs/16/sql-select.html#SQL-ORDERBY)):
 
 > If two rows are equal according to the leftmost expression, they are compared according to the next expression and so on. If they are equal according to all specified expressions, they are returned in an implementation-dependent order.
 
-SQLite ([3.39](https://www.sqlite.org/lang_select.html#the_order_by_clause)):
+SQLite ([3.45](https://www.sqlite.org/lang_select.html#the_order_by_clause)):
 
 > The order in which two rows for which all ORDER BY expressions evaluate to equal values are returned is undefined.
 

data/Rakefile

@@ -1,5 +1,7 @@
 # frozen_string_literal: true
 
+require "bundler/gem_tasks"
+
 begin
   require "rspec/core/rake_task"
 

data/lib/unreliable/build_order.rb

@@ -7,28 +7,45 @@ require "active_record/connection_adapters/abstract_adapter"
 module Unreliable
   module BuildOrder
     def build_order(arel)
-      super(arel)
+      super
 
+      adapter_name = unreliable_connection.adapter_name
       return unless Unreliable::Config.enabled?
+      return if distinct_on_postgres?(adapter_name)
+      return if distinct_on_sqlserver?(adapter_name)
       return if from_only_internal_metadata?(arel)
       return if from_one_table_with_ordered_pk?(arel)
 
-      case Arel::Table.engine.connection.adapter_name
-      when "Mysql2"
+      case adapter_name
+      when "Mysql2", "Trilogy"
         # https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_rand
         arel.order("RAND()")
 
+      when "SQLServer"
+        # https://learn.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql
+        arel.order("NEWID()")
+
       when "PostgreSQL", "SQLite"
-        # https://www.postgresql.org/docs/13/functions-math.html#FUNCTIONS-MATH-RANDOM-TABLE
+        # https://www.postgresql.org/docs/16/functions-math.html#FUNCTIONS-MATH-RANDOM-TABLE
         # https://www.sqlite.org/lang_corefunc.html#random
         arel.order("RANDOM()")
 
       else
-        raise ArgumentError, "unknown Arel::Table.engine"
+        raise ArgumentError, "unreliable: unknown adapter #{adapter_name.inspect}"
 
       end
     end
 
+    def distinct_on_postgres?(adapter_name)
+      distinct_value && adapter_name == "PostgreSQL"
+    end
+
+    def distinct_on_sqlserver?(adapter_name)
+      # SQL Server rejects ORDER BY expressions not in the select list when
+      # DISTINCT is used, so we don't append NEWID() to DISTINCT queries.
+      distinct_value && adapter_name == "SQLServer"
+    end
+
     def from_only_internal_metadata?(arel)
       # No need to randomize queries on ar_internal_metadata
       arel.froms.map(&:name) == [ActiveRecord::Base.internal_metadata_table_name]
@@ -51,13 +68,20 @@ module Unreliable
       # Using the SchemaCache minimizes the number of times we have to, e.g. in MySQL,
       # SELECT column_name FROM information_schema.statistics
       # (or in Rails < 6, SELECT column_name FROM information_schema.key_column_usage)
-      [ActiveRecord::Base.connection.schema_cache.primary_keys(arel.froms.first.name)].flatten
+      [unreliable_connection.schema_cache.primary_keys(arel.froms.first.name)].flatten
+    end
+
+    def unreliable_connection
+      # Rails 7.2+ soft-deprecated `connection` in favor of `lease_connection`.
+      # We check for it with klass (not self) because it works on Rails 7.2+ due to
+      # delegation, and it doesn't break Rails 5.2 due to a respond_to_missing bug.
+      klass.respond_to?(:lease_connection) ? lease_connection : connection
     end
 
     def order_columns(arel)
       from_table_name = arel.froms.first.name
       arel.orders
-        .select { |order| order.is_a? Arel::Nodes::Ordering } # Don't try to parse textual orders
+        .grep(Arel::Nodes::Ordering) # Don't try to parse textual orders
         .map(&:expr)
         .select { |expr| expr.relation.name == from_table_name }
         .map(&:name)

data/lib/unreliable/config.rb

@@ -7,15 +7,15 @@ module Unreliable
     end
 
     def self.enabled?
-      @enabled && Rails.env.test?
+      @enabled && !Thread.current[:unreliable_disabled] && Rails.env.test?
     end
 
     def self.disable
-      prev_enabled = @enabled
-      @enabled = false
+      was_disabled = Thread.current[:unreliable_disabled]
+      Thread.current[:unreliable_disabled] = true
       yield
     ensure
-      @enabled = prev_enabled
+      Thread.current[:unreliable_disabled] = was_disabled
     end
   end
 end

data/lib/unreliable/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Unreliable
-  VERSION = "0.9.1"
+  VERSION = "1.0.0"
 end

data/spec/adapter_option_spec.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+RSpec.describe "rspec adapter" do
+  it "is as specified" do
+    expect(ActiveRecord::Base.connection.adapter_name.downcase).to eq(UnreliableTest.find_adapter)
+  end
+end

data/spec/config_disable_nesting_spec.rb

@@ -0,0 +1,24 @@
+# frozen_string_literal: true
+
+RSpec.describe Unreliable::Config do
+  it "restores state after nested disable blocks" do
+    expect(Cat.all.to_sql).to end_with(adapter_rand("ORDER BY RANDOM()"))
+
+    Unreliable::Config.disable do
+      expect(Cat.all.to_sql).to_not include("RANDOM()")
+      expect(Cat.all.to_sql).to_not include("RAND()")
+
+      Unreliable::Config.disable do
+        expect(Cat.all.to_sql).to_not include("RANDOM()")
+        expect(Cat.all.to_sql).to_not include("RAND()")
+      end
+
+      # Still disabled after inner block
+      expect(Cat.all.to_sql).to_not include("RANDOM()")
+      expect(Cat.all.to_sql).to_not include("RAND()")
+    end
+
+    # Re-enabled after outer block
+    expect(Cat.all.to_sql).to end_with(adapter_rand("ORDER BY RANDOM()"))
+  end
+end

data/spec/config_thread_safety_spec.rb

@@ -0,0 +1,27 @@
+# frozen_string_literal: true
+
+# Config.disable must only suppress randomization in the calling thread.
+# Before the fix, @enabled was a class-level variable shared across threads,
+# so one thread's disable block would suppress randomization in all threads.
+
+RSpec.describe Unreliable::Config, "thread safety" do
+  it "does not affect other threads when disabled" do
+    other_thread_sql = nil
+    barrier = Queue.new
+
+    Unreliable::Config.disable do
+      # Our thread has randomization disabled
+      expect(Cat.all.to_sql).to_not include("RANDOM()")
+      expect(Cat.all.to_sql).to_not include("RAND()")
+
+      Thread.new do
+        other_thread_sql = Cat.all.to_sql
+        barrier.push(:done)
+      end
+
+      barrier.pop # wait for the other thread
+    end
+
+    expect(other_thread_sql).to include(adapter_rand("RANDOM()"))
+  end
+end

data/spec/env_spec.rb

@@ -3,14 +3,14 @@
 RSpec.describe Unreliable do
   it "does nothing in prod" do
     Rails.env = "production"
-    expect(Cat.where(word: "foo").to_sql).to end_with(%q(WHERE "cats"."word" = 'foo'))
+    expect(Cat.where(word: "foo").to_sql).to end_with(adapter_rand(%q(WHERE "cats"."word" = 'foo')))
   ensure
     Rails.env = "test"
   end
 
   it "does nothing in dev" do
     Rails.env = "development"
-    expect(Cat.where(word: "foo").to_sql).to end_with(%q(WHERE "cats"."word" = 'foo'))
+    expect(Cat.where(word: "foo").to_sql).to end_with(adapter_rand(%q(WHERE "cats"."word" = 'foo')))
   ensure
     Rails.env = "test"
   end

data/spec/examples.txt

@@ -1,39 +1,62 @@
-example_id                                 | status | run_time        |
------------------------------------------- | ------ | --------------- |
-./spec/env_spec.rb[1:1]                    | passed | 0.00346 seconds |
-./spec/env_spec.rb[1:2]                    | passed | 0.00049 seconds |
-./spec/model_cache_versioning_spec.rb[1:1] | passed | 0.03983 seconds |
-./spec/model_indexes_books_spec.rb[1:1]    | passed | 0.00152 seconds |
-./spec/model_indexes_books_spec.rb[1:2]    | passed | 0.00132 seconds |
-./spec/model_indexes_books_spec.rb[1:3]    | passed | 0.00108 seconds |
-./spec/model_indexes_cats_spec.rb[1:1]     | passed | 0.00105 seconds |
-./spec/model_indexes_cats_spec.rb[1:2]     | passed | 0.0015 seconds  |
-./spec/model_indexes_dreams_spec.rb[1:1]   | passed | 0.00313 seconds |
-./spec/model_indexes_dreams_spec.rb[1:2]   | passed | 0.00129 seconds |
-./spec/model_indexes_shelves_spec.rb[1:1]  | passed | 0.00178 seconds |
-./spec/model_indexes_shelves_spec.rb[1:2]  | passed | 0.00174 seconds |
-./spec/model_indexes_shelves_spec.rb[1:3]  | passed | 0.00076 seconds |
-./spec/model_indexes_shelves_spec.rb[1:4]  | passed | 0.00087 seconds |
-./spec/model_indexes_shelves_spec.rb[1:5]  | passed | 0.00079 seconds |
-./spec/model_indexes_shelves_spec.rb[1:6]  | passed | 0.00101 seconds |
-./spec/model_joins_spec.rb[1:1]            | passed | 0.01262 seconds |
-./spec/model_joins_spec.rb[1:2]            | passed | 0.00359 seconds |
-./spec/model_joins_spec.rb[1:3]            | passed | 0.01319 seconds |
-./spec/model_joins_spec.rb[1:4]            | passed | 0.00217 seconds |
-./spec/model_select_spec.rb[1:1]           | passed | 0.0007 seconds  |
-./spec/model_select_spec.rb[1:2]           | passed | 0.00093 seconds |
-./spec/model_select_spec.rb[1:3]           | passed | 0.00091 seconds |
-./spec/model_select_spec.rb[1:4]           | passed | 0.00127 seconds |
-./spec/model_subquery_spec.rb[1:1]         | passed | 0.00155 seconds |
-./spec/model_update_arel_10_spec.rb[1:1]   | passed | 0.00536 seconds |
-./spec/railtie_spec.rb[1:1]                | passed | 0.00013 seconds |
-./spec/railtie_spec.rb[1:2]                | passed | 0.00008 seconds |
-./spec/textual_order_spec.rb[1:1]          | passed | 0.00108 seconds |
-./spec/textual_order_spec.rb[1:2]          | passed | 0.00067 seconds |
-./spec/textual_order_spec.rb[1:3]          | passed | 0.00078 seconds |
-./spec/textual_order_spec.rb[1:4]          | passed | 0.00087 seconds |
-./spec/textual_order_spec.rb[1:5]          | passed | 0.00069 seconds |
-./spec/textual_order_spec.rb[1:6]          | passed | 0.00079 seconds |
-./spec/textual_order_spec.rb[1:7]          | passed | 0.00088 seconds |
-./spec/version_spec.rb[1:1]                | passed | 0.00151 seconds |
-./spec/version_spec.rb[1:2]                | passed | 0.0002 seconds  |
+example_id                                 | status  | run_time        |
+------------------------------------------ | ------- | --------------- |
+./spec/adapter_option_spec.rb[1:1]         | passed  | 0.00045 seconds |
+./spec/env_spec.rb[1:1]                    | passed  | 0.00516 seconds |
+./spec/env_spec.rb[1:2]                    | passed  | 0.00012 seconds |
+./spec/execute_queries_spec.rb[1:1]        | passed  | 0.00479 seconds |
+./spec/execute_queries_spec.rb[1:2]        | passed  | 0.00774 seconds |
+./spec/execute_queries_spec.rb[1:3]        | passed  | 0.00722 seconds |
+./spec/execute_queries_spec.rb[1:4]        | passed  | 0.00989 seconds |
+./spec/execute_queries_spec.rb[1:5]        | passed  | 0.01507 seconds |
+./spec/execute_queries_spec.rb[1:6]        | passed  | 0.006 seconds   |
+./spec/execute_queries_spec.rb[1:7]        | passed  | 0.00368 seconds |
+./spec/execute_queries_spec.rb[1:8]        | passed  | 0.00372 seconds |
+./spec/execute_queries_spec.rb[1:9]        | passed  | 0.00329 seconds |
+./spec/execute_subqueries_spec.rb[1:1]     | passed  | 0.00974 seconds |
+./spec/execute_subqueries_spec.rb[1:2]     | passed  | 0.00419 seconds |
+./spec/model_cache_versioning_spec.rb[1:1] | passed  | 0.00092 seconds |
+./spec/model_indexes_books_spec.rb[1:1]    | passed  | 0.00058 seconds |
+./spec/model_indexes_books_spec.rb[1:2]    | passed  | 0.0002 seconds  |
+./spec/model_indexes_books_spec.rb[1:3]    | passed  | 0.00007 seconds |
+./spec/model_indexes_cats_spec.rb[1:1]     | passed  | 0.00006 seconds |
+./spec/model_indexes_cats_spec.rb[1:2]     | passed  | 0.00009 seconds |
+./spec/model_indexes_dreams_spec.rb[1:1]   | passed  | 0.00008 seconds |
+./spec/model_indexes_dreams_spec.rb[1:2]   | passed  | 0.00007 seconds |
+./spec/model_indexes_shelves_spec.rb[1:1]  | passed  | 0.00053 seconds |
+./spec/model_indexes_shelves_spec.rb[1:2]  | passed  | 0.00022 seconds |
+./spec/model_indexes_shelves_spec.rb[1:3]  | passed  | 0.00008 seconds |
+./spec/model_indexes_shelves_spec.rb[1:4]  | passed  | 0.00006 seconds |
+./spec/model_indexes_shelves_spec.rb[1:5]  | passed  | 0.00007 seconds |
+./spec/model_indexes_shelves_spec.rb[1:6]  | passed  | 0.0001 seconds  |
+./spec/model_joins_spec.rb[1:1]            | passed  | 0.00405 seconds |
+./spec/model_joins_spec.rb[1:2]            | passed  | 0.0006 seconds  |
+./spec/model_joins_spec.rb[1:3]            | passed  | 0.00015 seconds |
+./spec/model_joins_spec.rb[1:4]            | passed  | 0.00024 seconds |
+./spec/model_select_distinct_spec.rb[1:1]  | passed  | 0.0001 seconds  |
+./spec/model_select_distinct_spec.rb[1:2]  | passed  | 0.00009 seconds |
+./spec/model_select_distinct_spec.rb[1:3]  | passed  | 0.00007 seconds |
+./spec/model_select_distinct_spec.rb[1:4]  | passed  | 0.00123 seconds |
+./spec/model_select_spec.rb[1:1]           | passed  | 0.00007 seconds |
+./spec/model_select_spec.rb[1:2]           | passed  | 0.00008 seconds |
+./spec/model_select_spec.rb[1:3]           | passed  | 0.00007 seconds |
+./spec/model_select_spec.rb[1:4]           | passed  | 0.00013 seconds |
+./spec/model_subquery_spec.rb[1:1]         | passed  | 0.00014 seconds |
+./spec/model_update_arel_10_spec.rb[1:1]   | passed  | 0.00123 seconds |
+./spec/railtie_spec.rb[1:1]                | passed  | 0.00003 seconds |
+./spec/railtie_spec.rb[1:2]                | passed  | 0.00003 seconds |
+./spec/textual_order_raw_spec.rb[1:1]      | passed  | 0.00009 seconds |
+./spec/textual_order_raw_spec.rb[1:2]      | passed  | 0.00007 seconds |
+./spec/textual_order_raw_spec.rb[1:3]      | pending | 0.00001 seconds |
+./spec/textual_order_raw_spec.rb[1:4]      | pending | 0 seconds       |
+./spec/textual_order_raw_spec.rb[1:5]      | passed  | 0.00007 seconds |
+./spec/textual_order_raw_spec.rb[1:6]      | passed  | 0.00006 seconds |
+./spec/textual_order_raw_spec.rb[1:7]      | passed  | 0.00006 seconds |
+./spec/textual_order_raw_spec.rb[1:8]      | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:1]          | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:2]          | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:3]          | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:4]          | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:5]          | passed  | 0.00006 seconds |
+./spec/textual_order_spec.rb[1:6]          | passed  | 0.00007 seconds |
+./spec/version_spec.rb[1:1]                | passed  | 0.00054 seconds |
+./spec/version_spec.rb[1:2]                | passed  | 0.00004 seconds |