| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
`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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:
With the model
class Topic
alias_attribute :heading, :title
end
The call
Topic.where(heading: 'The First Topic')
should yield the same result as
Topic.where(title: 'The First Topic')
This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.
This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.
Github #7839
*Godfrey Chan*
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
| |
|
| |
|
|
|
|
|
|
|
| |
parameters
Conflicts:
activerecord/lib/active_record/dynamic_matchers.rb
|
|
|
|
|
|
|
| |
Nothing should be raised anyway :smile:
Thanks @spastorino :heart:
https://github.com/rails/rails/pull/8202/files#r2112067
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling a query method on an attribute that was not selected by
an ActiveRecord query, an ActiveModel::MissingAttributeError is not
raised. Instead, a nil value is returned, which will return false once
cast to boolean.
This is undesirable, as we should not give the impression that we know
the attribute's boolean value when we haven't loaded the attribute's
(possibly) non-boolean value from the database.
This issue is present on versions going back as far as 2.3, at least.
|
|
|
|
|
| |
On reflection, it seems like a bit of a weird method to have on
ActiveRecord::Base, and it shouldn't be needed most of the time anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 14fc8b34521f8354a17e50cd11fa3f809e423592.
Reason: we need to discuss a better path from this removal.
Conflicts:
activerecord/lib/active_record/reflection.rb
activerecord/test/cases/base_test.rb
activerecord/test/models/developer.rb
|
|
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it returned an Array.
If you want an array, call e.g. `Post.to_a` rather than `Post.all`. This
is more explicit.
In most cases this should not break existing code, since
Relations use method_missing to delegate unknown methods to #to_a
anyway.
|
|
|
|
| |
`FinderMethods#exists?` finder method now returns *false* with the *false* argument
|
|
|
|
|
| |
previously dynamic finders only worked in combination with the actual
column name and not its alias defined with #alias_attribute
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature adds a lot of complication to ActiveRecord for dubious
value. Let's talk about what it does currently:
class Customer < ActiveRecord::Base
composed_of :balance, :class_name => "Money", :mapping => %w(balance amount)
end
Instead, you can do something like this:
def balance
@balance ||= Money.new(value, currency)
end
def balance=(balance)
self[:value] = balance.value
self[:currency] = balance.currency
@balance = balance
end
Since that's fairly easy code to write, and doesn't need anything
extra from the framework, if you use composed_of today, you'll
have to add accessors/mutators like that.
Closes #1436
Closes #2084
Closes #3807
|
| |
|
|
|
|
|
|
|
|
|
| |
reflection.
ActiveRecord::FinderMethods#construct_limited_ids_condition will raise
ThrowResult if the limited reflection comes back empty. The other callers
of #construct_limited_ids_condition handle this exception (more specifically,
the callers of construct_relation_for*), but #exists? didn't until now.
|
|
|
|
|
|
|
|
| |
This behavior was added in be4ecdcc87984e9421ff5d5c90d33f475e0fbc01.
Closes #1139.
Fixes #2553, #1141, #1623 and #2062.
|
|
|
|
| |
Module#methods are Symbols in Ruby >= 1.9
|
| |
|
| |
|
| |
|
| |
|
| |
|