* Update mysql2 to the latest version
Fixes keyword arguments warning:
brianmario/mysql2/pull/1084
Fixes taint mechanism deprecation warning:
brianmario/mysql2@785969fbce
* Update json to the latest version
Fixes warning from trying to access an uninitialized ivar, and
keyword arguments warning:
flori/json/commit/de14dea34074558dc671d7edc71513f0216ce21d
flori/json/commit/19da336333e63dc9dde7baea47b179e162b7568e
This adds a regression test that previously failed checking controllers
don't have multiple ancestors which include url_helpers or path_helpers.
This is checked by digging through the ancestors and seeing if they
include either the url_helpers_module or path_helpers_module and making
sure only one ancestor does that.
We usually don't test performance changes (and also would not prefer to
test implementation this closely), but because this has regressed in the
past, and I think it would be relatively easy to accidentally introduce
again, I think we should test this one.
Previously, every time this was called it would return a new module.
Every time a new controller is built, it had one of these module
included onto it (see AbstractController::Railties::RoutesHelper).
Because each time this was a new module we would end up with a different
copy being included on each controller. This would also include a
different copy on a controller than on its superclass (ex.
ApplicationController). Furthermore, each generated module also extended
the url helper modules.
+--------------+ +-------------+
| | | |
| path_helpers | | url_helpers | (named routes added here)
| | | |
+------+----+--+ +----+--+-----+
^ ^ ^ ^
| | | |
| +---------------+ |
| | | |
| | +-----------+ |
| | | |
+------+--+---+ +--+----+-----+
| | | |
| (singleton) +------+ url_helpers | (duplicated for each controller)
| | | |
+-------------+ +-----+-------+
^
|
|
+---------+-------+
| |
| UsersController |
| |
+-----------------+
The result of this is that when named routes were added to the two
top-level modules, defining those methods became extremely slow because
Ruby has to invalidate the class method caches on all of the generated
modules as well as each controller. Furthermore because there were
multiple paths up the inheritance chain (ex. one through
UsersController's generated module and one through
ApplicationController's genereated module) it would end up invaliding
the classes multiple times (ideally Ruby would be smarter about this,
but it's much easier to solve in Rails).
Caching this module means that all controllers should include the same
module and defining these named routes should be 3-4x faster.
This method can generate two different modules, based on whether
supports_path is truthy, so those are cached separately.
The javascript directory under app/ is in a singular form (app/javascript) but the documentation was mentionning it in the plural form (app/javascripts).
-
### Problem
In rails/rails@bbfab0b33a I introduced a change which outputs
a deprecation whenever a class inherits from ActiveJob::Base.
This has the negative effect to trigger a massive amount of
deprecation at boot time especially if your app is eagerloaded
(like it's usually the case on CI).
Another issue with this approach was that the deprecation will
be output no matter if a job define a `after_perform` callbacks
i.e.
```ruby
class MyJob < AJ::Base
before_enqueue { throw(:abort) }
end
# This shouldn't trigger a deprecation since no after callbacks are defined
# The change in 6.2 will be already safe for the app.
```
### Solution
Trigger the deprecation only when a job is abort
(during enqueuing or performing) AND a `after_perform`
callback is defined on the job.
* Keep consistent verb tenses
[ci skip]
* Add link to "creating your own events"
[ci skip]
* Move section on how to subscribe to events above list of events
The list of events is really long, and most people only care about a
specific event or type of event.
[ci skip]
Using words such as 'just', 'simply' and 'easy' implies to the reader
that the tasks they are trying to accomplish are tasks that anyone can
do, which might then frustrate them if they find it difficult to
complete.
This commit rephrases some usage of these words to aid understanding in
the readers without making them feel belittled.
[ci skip]
We should set the `@records` and `@loaded` ivar inside `#load` rather
than in `#exec_queries`. Since `#load` is running `#exec_queries` and
`@records` can only be assigned if `loaded?` is true and `@loaded` can
only be set if `loaded?` is true then `#load` should do the assignment.
This is cleaner but also we came across this while working on an
internal gem and realized that the ivar assignment was happening in the
wrong place.
Co-authored-by: Aaron Patterson <aaron.patterson@gmail.com>
In https://github.com/rails/rails/pull/36388,
we supported passing objects that `respond_to` `render_in`
to `render`, but _only_ in views.
This change does the same for controllers, as Rails
generally gives the expectation that `render` behaves
the same in both contexts.
Co-authored-by: Aaron Patterson <tenderlove@github.com>
As a follow-up to https://github.com/rails/rails/pull/37872,
this change introduces a class_names view helper
to make it easier to conditionally apply class names
in views.
Before:
<div class="<%= item.for_sale? ? 'active' : '' %>">
After:
<div class="<%= class_names(active: item.for_sale?) %>">
We've been using this helper in the GitHub monolith
since 2016.
Co-authored-by: Aaron Patterson <tenderlove@github.com>
- #37872 introduced a regression and you can't do
```html.erb
hidden_field_tag('token', value: [1, 2, 3])
```
This will result in a `<input type="hidden" value=""`>.
I chose `hidden_field_tag` and the `value` attribute as an example
but this issue applies to any tag helper and any attributes.
https://github.com/rails/rails/pull/37872#issuecomment-561806468
mention that the feature should only apply for "class" attribute.
This commit fix original intent of #37872
A querystring value should be allowed to include an equal sign `=`.
This is necessary to support passing `options` for a PostgresSQL connection.
```
development:
url: postgresql://localhost/railsdevapp_development?options=-cmysetting.debug=on
```
Before this PR, attempting to start the rails process with that configuration would result in an error:
```
> bundle exec rails console
Traceback (most recent call last):
49: from bin/rails:4:in `<main>'
48: from bin/rails:4:in `require'
...
1: from /rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `query_hash'
/rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `[]': invalid number of elements (3 for 1..2) (ArgumentError)
```
After this PR, rails can properly parse the configuration:
```
> bundle exec rails console
Loading development environment (Rails 6.1.0.alpha)
2.6.5 :001 > ActiveRecord::Base.connection.select_all("show mysetting.debug").to_a
(0.4ms) show mysetting.debug
=> [{"mysetting.debug"=>"on"}]
```
utilum