| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The improvments to the test runner's integration with minitest in commit
b6fc8e25a10cc4abdd03018798b180270d6c5d7f add methods to the Minitest
module that refer to the Rails module. Unfortunately, when the
minitest-rails gem is loaded, the reference is incorrectly resolved to
the Minitest::Rails module.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The changes introduced to through associations in c80487eb were quite
interesting. Changing `relation.merge!(scope)` to `relation =
relation.merge(scope)` should in theory never cause any changes in
behavior. The subtle breakage led to a surprising conclusion.
The old code wasn't doing anything! Since `merge!` calls
`instance_exec` when given a proc, and most scopes will look something
like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing
the return value, it's a no-op. However, removing the `merge` causes
`unscope` to break.
While we're merging in the rest of the chain elsewhere, we were never
merging in `unscope` values, causing a breakage on associations where a
default scope was being unscoped in an association scope (yuk!). This is
subtly related to #20722, since it appears we were previously relying on
this mutability.
Fixes #20721.
Fixes #20727.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Closes #20743.
The task `db:_dump` now only dumps the schema if
`ActiveRecord::Base.dump_schema_after_migration` is true. This has
effects:
- `db:migrate:up`
- `db:migrate:down`
- `db:forward`
- `db:rollback`
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We recommend using the `bin/` executables in our docs and guides.
Let's make sure that our tests execute the same code path.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Improve integration_tool documentation
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per railties/lib/rails/test_unit/railtie.rb, where it sets it explicitly.
This can be confirmed by starting a new Rails console session in a new app and running this code:
Rails.application.config.app_generators.rails[:integration_tool]
I also beefed up the documentation slightly to be more explicit about what this configuration setting does.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
To fix #20644
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Added a note on development kit for Windows Users. This is required as Windows users can get frustrated when their first rails project creation would fail as some native gem won't get built.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
fix pluralization in doc [ci skip]
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | | |
Minor addition to getting started guide for foreign_key description
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
references migration [ci skip]
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These classes are part of Active Record Preloader, which is not part of
the public API.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
fix NoMethodError that occurs when generating scaffold inside full mode engine
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Passing nil to image_tag
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| |_|_|_|_|/ / /
|/| | | | | | | |
Fix cache issue when different partials use the same collection
|
| |/ / / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Adds the `virtual_path` option to `cache_fragment_name` so it can
be provided when needed.
That allows `cache_collection_render` to get the appropriate cache
key with the digest generated based on the template and prevent
collision with other templates that cache the same collection.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
[ci skip] Fix action_controller_overview
|
| |/ / / / / / / |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Closes #20705.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
With this change, we will always assume the association name is the same
as the table it's referencing. This is subtly different than treating
the hash key passed to `where` as the table name, as it still allows the
class referenced by the association to provide additional type
information.
After exploring several possible solutions to the ambiguity problem, I
do not think there is a short term answer that will maintain backwards
compatibility.
This change will make it so the following code does not work:
class User
has_many :approved_posts, -> { where(approved: true) }, class_name: "Post"
end
User.where(approved_posts: { id: 1 })
But prevents potential ambiguity and collision as demonstrated in [this
gist](https://gist.github.com/senny/1ae4d8ea7b0e269ed7a0).
Unfortunately, truely solving this requires significantly
re-architecting this code, so that what is currently represented as an
`Arel::Attribute` is instead another data structure that also references
the association it is representing, so we can identify the proper table
name for aliasing when we construct the final tree.
While I'd still like to accomplish that in the long run, I don't think
I'll be able to get there in time for Rails 5 (since I'm not full time
OSS any more, and this is several weeks worth of work). I'm hoping to
achieve this for Rails 5.1.
Fixes #20308
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Using `assert_predicate` and `assert_match` instead of just `assert` is
preferrable because better error messages are output.
In the case of `assert response.cookies.empty?` the error message was
`Failed assertion, no message given.` but now with `assert_predicate` it
will be `Expected {"user_name"=>"david"} to be empty?.`
For `assert_match(/user_name=david/,
response.headers["Set-Cookie"])` as well, the message returned was
unhelpful - `Failed assertion, no message given.` but now will tell what
was expected and what was returned with `Expected /user_name=david/ to
match "user_name=nope; path=/".`
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Allow default_render to take a block to customize behavior when there's no template
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
In 0de4a23 the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content. This is a breaking
change and some gems rely on this happening.
To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Maintaining consistency in wording [ci skip]
|
| |/ / / / / / / /
| | | | | | | |
| | | | | | | | |
"reproduce" word is better suited then "replicate" as its also used at other places in this same document having same context. It will then be consistent across document.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Remove `config` options from `default_options` in `railties`
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Fixes #20345.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Improve Validation Helpers' documentation comments and tests
|
| |/ / / / / / / / / |
|
| |\ \ \ \ \ \ \ \ \
| |_|_|_|/ / / / /
|/| | | | | | | | |
Change documentation for collection.build and collection.create [ci-skip]
|
| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
More granular console SQL coloration
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This new coloration approach makes it easier to scan the rails console
for specific types of activity with more fine-grained visual cues.
Virtual terminal ANSI color escape codes are used when displaying SQL
statements in the rails console. The former implementation alternates
line prefix information (including the statement name and execution
latency) between CYAN and MAGENTA. This visually differentiates any SQL
statements in the log and is useful for quickly scanning for database
activity.
While a great idea and a solid foundation, alternating between just two
colors on an even/odd basis (much like striping an HTML table) can be
improved upon.
This patch replaces the even/odd striping with a more comprehensive
scheme that applies coloration based on the type of statement being
run. Every statement logged has its prefix (name and latency) colored
white (as the statement body was previously). The statement body is now
colored according to the nature of the statement:
- INSERT statements are GREEN (symbolic of creation or genesis)
- SELECT statements are BLUE (typically used for informational
displays, as SELECT statements do not normally have side-effects)
- DELETE statements are RED (commonly used to indicate the danger of
a destructive action)
- UPDATE statements are YELLOW (it's like a less extreme RED :P)
- TRANSACTION statements are CYAN (arbitrary)
- and any other statements are MAGENTA (again, arbitrary)
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
vngrs/foreign_key_with_table_name_suffix_and_prefix
Add table name prefix and suffix support for foreign keys
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
remove_foreign_key methods
fix tests
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Add reversible syntax for change_column_default
|
| | | | | | | | | | | | | |
|
| | | |_|_|_|_|_|/ / / /
| |/| | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Passing `:from` and `:to` to `change_column_default` makes this command
reversible as user has defined its previous state.
So, instead of having the migration command as:
change_column_default(:posts, :state, "draft")
They can write it as:
change_column_default(:posts, :state, from: nil, to: "draft")
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Change routes.rb look in getting started
|
| | | |_|_|_|/ / / / / /
| |/| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / /
|/| | | | | | | | | | |
correct `file_fixture_path` in plugins `test_helper.rb`
|
| | | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
`fixture_path` does not end with a slash
|
| |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | | |
Improve detection of partial templates eligible for collection caching.
|
| | | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
The regular expression which was used to detect partial templates that
begin with a `<% cache ... do %>` call missed some cases. This commits
attempts to improve the detection for some cases such as multi-line
comments at the beginning of the template. The different templates are
listed in two new unit test methods.
Note that specially crafted Ruby code can still evade such `cache`-call
detection: for example, a user might have its own method which itself
calls the Rails `cache` helper. In such a case, the template's code
doesn't start with a literal `cache` string and therefore will not be
eligible for collection caching.
|
| |\ \ \ \ \ \ \ \ \ \ \ \
| |_|_|/ / / / / / / / /
|/| | | | | | | | | | | |
Update .pluck documentation on uniq
|
| |/ / / / / / / / / / /
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
This is to show users that they can chain `.uniq` and `.pluck` to get
the `DISTINCT column` result. They don't have to do `DISTINCT column`
themselves.
|
