| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Combine aliased_table_for and aliased_name_for
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This refactoring reduces the number of conditionals needed to build
`aliased_table_for` and removes `aliased_name_for` because it's no
longer necessary.
`aliased_name_for` was also used in `JoinDependency#initialize` so
that was replaced with `aliased_table_for` as well.
|
|/ |
|
|
|
|
|
|
|
| |
This allows us so abstract the migration from the type that is actually
used by Rails. For example, ":string" may be a varchar or something,
but the framework does that translation, and the app shouldn't need to
know.
|
| |
|
| |
|
|\
| |
| | |
Explain that default_scope also influences update_all
|
| |
| |
| | |
It now contains a carefully formulated reference to the "current relation" which might help clarify that the receiving will generate its own scope, escaping the need for explicitly referencing `default_scope` which is, after all, just another way of specifying a scope and nothing special.
|
| |
| |
| |
| |
| | |
This was not explicitly stated before and I needed to try it out to be
certain. A little explicit statement in the API docs might help here.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some comments that are meant to separate blocks of code in a file show up
on http://api.rubyonrails.org as though they were part of the documentation.
This commit hides those comments from the documentation.
Stems from the discussion with @zzak at https://github.com/voloko/sdoc/issues/79#issuecomment-64158738
[ci skip]
|
| |
| |
| |
| |
| | |
Thanks to @thedarkone for pointing out that an instance of this object
is used in a shared context.
|
|\ \
| | |
| | | |
Fix includes on association with a scope
|
| | |
| | |
| | |
| | | |
on the joined assoiciation
|
| | | |
|
| | |
| | |
| | |
| | | |
See also PR: #17610
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`.reflections` public API changed to return a String instead of a Symbol
as keys.
see commit 1f31488499111fdfce79d8dc1cc8fb008f7cdb25 and 6259e4e2dcca9a79f22f96658c33efe81936bc0d
[fixes #16928]
[fixes #17610]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For some reason changing `.find` to `.unscoped.find` in
https://github.com/rails/rails/commit/f766abd4cf3eb75469d3646cfb6d85e668c619f3
caused `scoping` to leak in some tests when run in isolation (looks like
a concurrency issue?). `relation_scoping_test.rb` is a case that failed.
From what I can tell it should not be possible, but changing to the
block form fixes it. There is a deeper issue that I can't seem to find.
/cc @senny
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also checked to make sure this does not affect foreign key constraints.
(It doesn't).
Fixes #12856
Closes #14088
|
|/ /
| |
| |
| | |
We can't change the signature without a deprecation cycle.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Prior to this patch you'd end up with an error like:
```
ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)]
```
|
|\ \
| | |
| | | |
Wrap code snippets in +, not backticks, in sdoc [ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I grepped the source code for code snippets wrapped in backticks in the comments
and replaced the backticks with plus signs so they are correctly displayed in
the Rails documentation.
[ci skip]
|
|/ / |
|
|\ \
| | |
| | | |
PERF: avoid string allocations
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
This makes the following changes:
* warn if `:null` is not passed to `add_timestamps`
* `timestamps` method docs link to `add_timestamps` docs
* explain where additional options go
* adjust examples to include `null: false` (to prevent deprecation warnings)
|
|\ \
| | |
| | | |
Allow class_name option in habtm to be consistent with other association...
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It doesn't make sense for the subclass to implement this method, and not
have it on the parent. We can also DRY up the implementation of
`#lookup` to be defined in terms of fetch, which will give us a single
point of entry
|
| | | |
|
| | |
| | |
| | |
| | | |
This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
dtaniwaki/support-symbol-foreign-key-column-to-delete
Support symbol foreign key to delete
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 6f7910a and 52c70d4.
Query params are type cased through the same method, so this approach doesn't work.
|
| | | |
| | | |
| | | |
| | | | |
See comment on 6f7910a
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't have the check the range when the value is coming from the DB, so
override type_cast_from_database to short-circuit the extra work.
type_cast_from_database (small) 3437507.5 (±29.2%) i/s - 14223135 in 4.996973s
type_cast_from_database (large) 3158588.7 (±28.3%) i/s - 13265628 in 4.992121s
type_cast (small) 481984.8 (±14.2%) i/s - 2352012 in 5.005694s
type_cast (large) 477331.8 (±14.2%) i/s - 2332824 in 5.012365s
Comparison:
type_cast_from_database (small): 3437507.5 i/s
type_cast_from_database (large): 3158588.7 i/s - 1.09x slower
type_cast (small): 481984.8 i/s - 7.13x slower
type_cast (large): 477331.8 i/s - 7.20x slower
The difference is huge but the absolute gain is quite small. That being said
this is a hotspot and it showed up on the radar when benchmarking discourse.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We added a comparison to "id", and call to `self.class.primary_key` a
*lot*. We also have performance hits from `&block` all over the place.
We skip the check in a new method, in order to avoid breaking the
behavior of `read_attribute`
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't have the check the range when the value is coming from the DB,
so override type_cast_from_database to short-circuit the extra work.
The difference is huge but the absolute gain is quite small. That being
said this is a hotspot and it showed up on the radar when benchmarking
discourse.
|
| | | |
| | | |
| | | |
| | | | |
This appears to be a performance hotspot, see #17655.
|
| | | | |
|
| |_|/
|/| |
| | |
| | | |
Performance improvement, as well as improved code clarity
|
|/ / |
|
| |
| |
| |
| | |
Oh hey, we got to remove some code because of that!
|
| |
| |
| |
| |
| |
| | |
Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used
|
| |
| |
| |
| |
| |
| | |
If something causes the teardown block to not get run (errors,
interrupting test runs), we have to manually delete them, which is a
pain.
|
| |
| |
| |
| |
| |
| | |
This caused a pretty major performance regression for 4.2, as this is a
hotspot for query construction. We're still slightly slower than 4.1,
but it's much less significant.
|