The `index_exists?` method wasn't very specific so when we added the
`if_not_exists` to `add_index` and `if_exists` to `remove_index` there
were a few cases where behavior was unexpected.
For `add_index` if you added a named index and then added a second index
with the same columns, but a different name, that index would not get
added because `index_exists` was looking only at column named and not at
the exact index name. We fixed `add_index` by moving the `index_exists`
check below `add_index_options` and pass `name` directly to
`index_exists` if there is a `if_not_exists` option.
For `remove_index` if you added a named index and then tried to remove
it with a nil column and a explicit name the index would not get removed
because `index_exists` saw a nil column. We fixed this by only doing the
column check in `index_exists` if `column` is present.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
If a parameter isn't found we can suggest similar params:
```
class BooksController < ActionController::Base
def create
params.require(:book).require(:name)
head :ok
end
end
post :create, params: { magazine: { name: "Mjallo!" } }
param is missing or the value is empty: book
Did you mean? controller
action
magazine
post :create, params: { book: { title: "Mjallo!" } }
param is missing or the value is empty: name
Did you mean? title
```
If a has_many :through association isn't found we can suggest similar associations:
```
class Author
has_many :categorizations, -> { }
has_many :categories, through: :categorizations
has_many :categorized_posts, through: :categorizations, source: :post
has_many :category_post_comments, through: :categories, source: :post_comments
has_many :nothings, through: :kateggorisatons, class_name: "Category"
end
Author.first.nothings
Could not find the association :kateggorisatons in model Author
Did you mean? categorizations
categories
categorized_posts
category_post_comments
```
- Add the configuration option for annotating templates with file names to the generated app.
- Add `annotate_rendered_view_with_filenames` option to configuring guide.
* Update `fixture_file_upload` documentation to reflect recent changes. [ci skip]
* Friendlier deprecation message for `fixture_file_upload`.
Suggested change now can be copied and pasted into the code without modification.
I caught two references that seemed inconsistent:
1. In section 2.2 Binding a Form to an Object, the code snippet variable was called `form`, but in the bullet points below, it was referenced as `f`.
2. In section 6 Uploading Files, the references to the params hash returned by two different forms was incorrect.
Currently the query values normalization for multiple values is missing
some parts.
Some values are flatten, but others are not flatten.
Some values are compact, but others are not compact.
some values are compact_blank, but others are not compact_blank.
Originally all multiple values should be flatten and compact_blank
before `build_arel`, if it is not ensured which multiple values are
normalized or not, we need to normalize it again carefully and
conservatively in `build_arel`.
To unify the query values normalization for multiple values, ensure the
normalization in `check_if_method_has_arguments!` since all multiple
values should be checked by the method.
* master-sec:
Check that request is same-origin prior to including CSRF token in XHRs
HMAC raw CSRF token before masking it, so it cannot be used to reconstruct a per-form token
activesupport: Avoid Marshal.load on raw cache value in RedisCacheStore
activesupport: Avoid Marshal.load on raw cache value in MemCacheStore
Return self when calling #each, #each_pair, and #each_value instead of the raw @parameters hash
Include Content-Length in signature for ActiveStorage direct upload
If an action isn't found on a controller we can suggest similar actions:
```
The action 'indx' could not be found for SimpleController
Did you mean? index
```
`HomogeneousIn` has changed merging behavior for NOT IN clause from
before. This changes `equality?` to return true only if `type == :in` to
restore the original behavior.
Related #39236.
`relation.merge` method sometimes replaces mergee side condition, but
sometimes maintain both conditions unless `relation.rewhere` is used.
It is very hard to predict merging result whether mergee side condition
will be replaced or not.
One existing way is to use `relation.rewhere` for merger side relation,
but it is also hard to predict a relation will be used for `merge` in
advance, except one-time relation for `merge`.
To address that issue, I propose to support merging option `:rewhere`,
to allow mergee side condition to be replaced exactly.
That option will allow non-`rewhere` relation behaves as `rewhere`d
relation.
```ruby
david_and_mary = Author.where(id: david.id..mary.id)
# both conflict conditions exists
david_and_mary.merge(Author.where(id: bob)) # => []
# mergee side condition is replaced by rewhere
david_and_mary.merge(Author.rewhere(id: bob)) # => [bob]
# mergee side condition is replaced by rewhere option
david_and_mary.merge(Author.where(id: bob), rewhere: true) # => [bob]
```
If an association isn't found we can suggest matching associations:
```
Post.all.merge!(includes: :monkeys).find(6)
Association named 'monkeys' was not found on Post; perhaps you misspelled it?
Did you mean? funky_tags
comments
images
skimmers
```
In aggregation value's type cast, `klass.attribute_types.fetch(...)`
will find no type almost all cases, since any type is already returned
by `column.type_caster` in that case.
And also, the root of join dependency tree is also the model's `klass`,
so the explicit `klass.attribute_types` is redundant originally.
