| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
robertjlooby/fix_overwriting_by_dynamic_finders"
This reverts commit d5ba9a42a6e93b163a49f99d739aa56820e044d0, reversing
changes made to 30c503395bf6bf7db1ec0295bd661ce644628db5.
Reason: This generate the dynalic finders more than one time
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If there is a method defined such as `find_and_do_stuff(id)`, which then
gets called on an association, we will perform statement caching and the
parent ID will not change on subsequent calls.
Fixes #18117
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This ensures that we're handling all forms of nested tables the same way.
We're aware that the `convert_dot_notation_to_hash` method will cause a
performance hit, and we intend to come back to it once we've refactored some of
the surrounding code.
[Melissa Xie & Melanie Gilman]
|
| |
|
|
|
|
|
| |
`Computer` class needs to be require
See #17217 for more details
|
|
|
|
|
| |
We should not behave differently just because a class has a default
scope.
|
|
|
|
|
|
|
|
|
|
|
| |
Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.
Fixes #17380
|
|
|
|
|
|
|
|
|
| |
For now, we will just skip the cache when a non-column key is used in the hash.
If the future, we can probably move some of the logic in PredicateBuilder.expand
up the chain to make caching possible for association queries.
Closes #16903
Fixes #16884
|
|\
| |
| | |
Update RecordNotFound exception cases to include a message with the
|
| |
| |
| |
| | |
Model that the Record was not found in.
|
| |
| |
| |
| |
| |
| |
| |
| | |
`User.where(id: [[1,2],3])` was equal to `User.where(id:[1, 2, 3])`
in Rails 4.1.x but because of some refactoring in Arel this stopped
working in 4.2.0. This fixes it in Rails.
[Dan Olson & Cristian Bica]
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Also duplicated find_by tests from relations_test.rb to finder_test.rb now
that we have a completely different implementation on the class (in core.rb
with AST caching stuff).
* Also removed a (failing) test that used mocks. Now that we have tests for the
behavior, there's no point having another test that tests the implementation
(that it delegates). Further, what the test was implying is nolonger true with
the current implementation, because Class.find_by is a real method now.
|
| |
| |
| |
| | |
Fixes #15821.
|
| |
| |
| |
| | |
Looks like #first wasn't warm enough...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.
As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.
|
|/
|
|
|
|
|
|
| |
```
activerecord/test/cases/adapters/postgresql/range_test.rb:159: warning: (...) interpreted as grouped expression
activerecord/test/cases/finder_test.rb:38: warning: shadowing outer local variable - e
activerecord/test/cases/finder_test.rb:43: warning: shadowing outer local variable - e
```
|
| |
|
| |
|
|
|
|
| |
`exists?`
|
|
|
|
|
| |
Pass the id of the object to the method by calling `.id` on the AR
object.
|
| |
|
|
|
|
| |
This will avoid the confusing flunk logic
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When we build a query with an inline value that is a numeric (e.g.
because it's out of range for an int4) PostgreSQL doesn't use an index
on the column, since it's now comparing numerics and not int4s.
This leads to a _very_ slow query.
When we use bound parameters instead of inline values PostgreSQL
raises numeric_value_out_of_range since no automatic coercion happens.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes two regressions introduced in cafe31a078 where
newly created finder methods #second, #third, #forth, and #fifth
caused a NoMethodError error on reload associations and where we
were pulling the wrong element out of cached associations.
Examples:
some_book.authors.reload.second
# Before
# => NoMethodError: undefined method 'first' for nil:NilClass
# After
# => #<Author id: 2, name: "Sally Second", ...>
some_book.first.authors.first
some_book.first.authors.second
# Before
# => #<Author id: 1, name: "Freddy First", ...>
# => #<Author id: 1, name: "Freddy First", ...>
# After
# => #<Author id: 1, name: "Freddy First", ...>
# => #<Author id: 2, name: "Sally Second", ...>
Fixes #13783.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit bring the famous ordinal Array instance methods defined
in ActiveSupport into ActiveRecord as fully-fledged finders.
These finders ensure a default ascending order of the table's primary
key, and utilize the OFFSET SQL verb to locate the user's desired
record. If an offset is defined in the query, calling #second adds
to the offset to get the actual desired record.
Fixes #13743.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This will fix the [broken
test](https://github.com/rails/rails/commit/4a2650836680f51490e999c3c8441a2f9adff96e)
`test_with_limiting_with_custom_select`.
The query's result was built in a hash with column name as key, if the
result have a duplicated column name the last value was
overriding the first one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dynamic finder was creating the method signature with the parameters name,
which may have reserved words and this way creating invalid Ruby code.
Closes: #13261
Example:
# Before
Dog.find_by_alias('dog name')
# Was creating this method
def self.find_by_alias(alias, options = {})
# After
Dog.find_by_alias('dog name')
# Will create this method
def self.find_by_alias(_alias, options = {})
|
| |
|
|
|
|
| |
Closes #7441
|
|
|
|
| |
We need to fix this test
|
| |
|
|
|
|
| |
This will avoid the broken window effect in our test suite
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression. The documentation said in its introduction
paragraph that the method returns truthy/falsy, but then below it
was said that if there were no arguments you'd get `true` or `false`.
Also when the argument is exactly `false` a singleton is documented
to be returned.
The method was not returning the singletons so it didn't conform to
those special cases.
The best solution here seems to be to just return singletons in all
cases. This solution is backwards compatible. Also, the contract
has been revised because it has no sense that the predicate varies
that way depending on the input. I bet the previous contract was just
an accident, not something mixed on purpose.
Conflicts:
activerecord/lib/active_record/relation/finder_methods.rb
activerecord/test/cases/finder_test.rb
|
|
|
|
| |
This method is already present in helper.rb
|
|
|
|
|
|
|
| |
Some adapters require column information to do their job properly.
By enforcing the provision of the column for this internal method
we ensure that those using adapters that require column information
will always get the proper behavior.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.
Rather than build a select distinct clause in #construct_limited_ids_condition,
I set #distinct! and pass just the columns into the select statement.
This requires introducing a #columns_for_distinct method to return the
select columns but not the statement itself.
|