Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where with block #1

Open
wants to merge 36 commits into
base: master
Choose a base branch
from
Open

Where with block #1

wants to merge 36 commits into from

Conversation

brunvez
Copy link
Owner

@brunvez brunvez commented May 26, 2020

Summary

Other Information

jhawthorn and others added 21 commits May 19, 2020 18:55
We don't have jbuilder installed (this would work if it was).
The template resolver is supposed to determine the handler, format, and
variant from the path in extract_handler_and_format_and_variant.

This commit adds tests for how variants are parsed from the filenames
found in the resolver. It includes two skipped tests which currently fail.
The template resolver is supposed to determine the handler, format, and
variant from the path in extract_handler_and_format_and_variant.

Previously this behaviour was close but didn't exactly match the
behaviour of finding templates, and in some cases (particularly with
handlers or formats missing) would return incorrect results.

This commit introduces Resolver::PathParser, a class which should be
able to accurately from any path inside a view directory be able to tell
us exactly the prefix, partial, variant, locale, format, variant, and
handler of that template.

This works by building a building a regexp from the known handlers and
file types. This requires that any resolvers have their cache cleared
when new handlers or types are registered (this was already somewhat the
requirement, since resolver lookups are cached, but this makes it
necessary in more situations).
details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
Before rails#36604, `enum` and `set` columns were incorrectly dumped as a
`string` column.

If an `enum` column is defined as `foo enum('apple','orange')`, it was
dumped as `t.string :foo, limit: 6`, the `limit: 6` is seemed to
restrict invalid string longer than `'orange'`.

But now, `enum` and `set` columns are correctly dumped as `enum` and
`set` columns, the limit as longest element is no longer used.
…attribute nodes

Related to rails#7380 and rails#7392.

`merge` allows to overwrite non-attribute nodes by rails#7392, so
`merge(..., rewhere: true)` should also have the same ability, to
migrate from the half-baked current behavior to entirely consistent new
behavior.
Remove unused `limit` on `enum` and `set` columns in MySQL
`merge(..., rewhere: true)` should have the ability to overwrite non-attribute nodes
rails#39378 has changed to use `build_scope` in `join_scopes`, which rely on
`reflection.klass`, but `reflection.klass` is restricted for polymorphic
association, the klass for the association should be passed explicitly.
…c_association

Fix preloading for polymorphic association with custom scope
Prior to this commit, a `dup`ed record and its originating record would
share the same `Attached` proxy objects.  Those proxy objects, in turn,
would point to the same `Attachment` associations, causing changes made
through the proxy interface to affect both records.
Add status the 103 Early Hints as Not content for action_dispatch
…tent_type

Remove dup from Request#set_cotent_type
* Remove dup from post body for forcing encoding

* Properly assign raw_post variable to encoded version

Co-authored-by: Ryuta Kamizono <kamipo@gmail.com>
kamipo and others added 8 commits May 27, 2020 01:25
It is safer than direct mutation.
A few action_controller docs corrections [skip ci]
No need to extend ActionController::Caching by ActiveSupport::Autoload
A Rails view may rely on several templates (e.g. layouts and partials)
in addition to the template for the action being rendered (e.g.
"show.html.erb"). To track which view file is currently being rendered
for the purpose of generating template tree digests used in cache
fragment keys, Action View uses a stack, the top item of which is
accessed via the @current_template variable (introduced in 1581cab).

Consider the following template:

    <!-- home.html.erb -->
    <%= render layout: "wrapper" do %>
      <%= cache "foo" %>
        HOME
      <%= end %>
    <%= end %>

Inside the block passed to the render helper, @current_template
corresponds to the wrapper.html.erb template instead of home.html.erb.
As wrapper.html.erb is then used as the root node for generating the
template tree digest used in the cache fragment key, the cache fragment
fails to expire upon changes to home.html.erb. Additionally, should a
second template use the wrapper.html.erb layout and contain a cache
fragment with the same key, the cache fragment keys for both templates
will be identical - causing cached content to "leak" from one view to
another (as described in rails#38984).

This commit skips adding templates to the stack when rendered as a
layout with a block via the render helper, ensuring correct and unique
cache fragment digests. Additionally, the virtual_path keyword arguments
found in CacheHelper and all references to the are removed as they no
longer possess any function. (Following the introduction of
@current_template, virtual_path is accessed via
@current_template.virtual_path rather than as a standalone variable.)
Following the introduction of the @current_template variable in 1581cab,
the @virtual_path variable is now redundant, as the value of the virtual
path may be accessed via @current_template.virtual_path. This commit
removes @virtual_path and replaces any references to @virtual_path with
@current_template.virtual_path.
Ensure cache fragment keys (i.e. dependency tree digests) include all relevant templates
`assert_no_queries` sometimes fails due to counting implict schema info
load queries, most case that is enough to just ignore it.

https://buildkite.com/rails/rails/builds/69598#321bb1bc-ec67-40cd-813f-68dc7809ddde/1444-1452
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.