This removes the singularize from `where` which runs on all `expand_from_hash` keys which might be reflections or column names. This saves a lot of time by avoiding singularizing column names.
Previously in https://github.com/rails/rails/pull/45163 the singularize was removed entirely. after some reflection, I think it is better to at least give a warning for one release since `where` is a very popular API and the problems you can run into with incorrect relation could be hard to debug.
Configurable with `ActiveRecord::Base.allow_deprecated_singular_assocaitions_name = false` / `config.active_record.allow_deprecated_singular_assocaitions_name = false`
The `assert_called_with` helper allows passing a multi-dimensional array to
mock multiple calls to the same method for a given block. This works
fine now, but when adding support for real kwargs arguments to line up with
recent upgrades in Minitest, this approach is no longer workable because
we can't pass multiple sets of differing kwargs.
Rather than complicated this method further, this commit removes the
multi-call form of `assert_called_with` and modifies the tests that
currently make use of that functionality to just use the underlying
`Minitest::Mock` calls.
Co-authored-by: Eileen M. Uchitelle <eileencodes@gmail.com>
Per this discussion: https://github.com/rails/rails/pull/45346#discussion_r898376510
The adapter should read from `database.yml`, if a value is provided for `strict`. If no value is provided then it should fall back to `config.active_record.strict_strings_by_default`.
Co-authored-by: fatkodima123 <fatkodima123@gmail.com>
It's possible for `ActionView::Helpers::FormTagHelper#field_name` calls
made by instances constructed through `fields` and `fields_for` helpers
to have an `object_name` argument that's `nil`. For example, the
following will raise an `undefined method `empty?' for nil:NilClass`
exception:
```erb
<%= fields do |f| %>
<%= f.field_name :body %>
<% end %>
```
To guard against those calls, replace the method's call to
`String#empty?` with `Object#blank?`, since `NilClass#empty?` is not
defined.
In #45162 it was discovered that the multi_db generator that was created
for 7.0 doesn't work correctly because that file is loaded _after_ the
initializer in active record is run. I tried moving everything to an
after_initialize but the middleware stack is frozen at that point. I
also attempted to fix this in #45353 but it just didn't feel right to
have to deprecate this behavior that _should_ work.
I then realized that most of the middleware in Rails is installed in the
middleware stack file in railties. If I move the middleware installation
to this file, everything works as necessary.
The only caveat is we need to check if `config` responds to
`active_record` but I think that should be fine - we already do that in
the framework defaults configuration.
Fixes#45162
CI runs bundle update so minitest got updated and my PR started failing
due to this change 6e06ac9d3e
I will relax the minitest requirement once the failing specs can be
fixed, but I don't want that to block this. It wasn't immediately
obvious to me what needs to change in our tests to get them passing.
There is also an open issue here
https://github.com/minitest/minitest/issues/912 regarding this change.
The current Command Line guide has an advanced section describing
specifying git as SCM and PostgreSQL as the database. This section is
easily overlooked: https://github.com/rails/rails/issues/44325
By moving whole "advanced" section under the `rails new` section, it's
easier to find. Also specifying the database is pretty common I guess
and not an "advanced" topic.
All mentions of the SCM option have been removed, as it seems to no
longer be an option and we always initialize with Git only.
If you use either of these frameworks, Active Job is used. That means
that only skipping Active Job will not really skip it, and whenever
app:update runs, Active Job will be added back.
Currently, when #reset is called on a relation object it does not reset
the cache_versions ivar. This can lead to a confusing and buggy
situation where despite having the correct data the relation is still
reporting a stale cache_version. Resetting this ivar along with the
other relation state corrects this situation.
Update test assertion
Assert the specific cache_version matches the latest .all relation
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
This used to be `config.secret_key_base` but was changed to
`secrets.secret_key_base` in ae75289 and the `secrets.` prefix was
removed in ca18922 when credentials were added.
`secret_key_base` by itself doesn't really fit with the rest of this
section, so the header and description were changed to document the
config value explicitly, and a reference was added to the api docs for
the recommended approaches at setting its value.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
