assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
When `group` is used in combination with any calculation method, the
resulting hash uses the grouping expression as the key. Currently we're
incorrectly always favoring the type reported by the query, instead of
the type known by the class. This causes differing behavior depending on
whether the adaptor actually gives proper types with the query or not.
After this change, the behavior will be the same on all adaptors -- we
see if we know the type from the class, fall back to the type from the
query, and finally fall back to the identity type.
Fixes#25595
Closes#21922
Let `Book(id, author_id)`, `Photo(id, book_id, author_id)` and `Author(id)`
Running `Book.group(:author_id).joins(:photos).count` will produce:
* Rails 4.2 - conflicts `author_id` in both projection and group by:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY author_id
```
* Master (9d02a25) - conflicts `author_id` only in projection:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY "books"."author_id"
```
* With this fix:
```sql
SELECT COUNT(*) AS count_all, "books"."author_id" AS books_author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY "books"."author_id"
```
It allows a query like `User.select(:name).count` to be written
using Arel as `User.select(User.arel_table[:name]).count`.
It exposes the calculations API to accept Arel nodes:
`User.count(User.arel_table[:name])`, `User.sum(User.arel_table[:id])`,
`Account.average(Account.arel_table[:credit_limit])`,
`Account.maximum(Account.arel_table[:credit_limit])` and
`Account.minimum(Account.arel_table[:credit_limit])`.
This matches our behavior in other cases where useful enumerable methods
might have a different definition in `Relation`. Wanting to actually
enumerate over the records in this case is completely reasonable, and
wanting `.sum` is reasonable for the same reason it is on `Enumerable`
in the first place.
This allows easier integration with ActiveRecord, such that
AR#pluck will now use Enumerable#pluck if the relation is loaded,
without needing to hit the database.
See #9683 for the reasons we switched to `distinct`.
Here is the discussion that triggered the actual deprecation #20198.
`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.
association
While joining table of has_many :through association, ActiveRecord will
use the actual table name instead of through-join alias. It results with
a wrong SQL and exception is raised. This only happens when calculation
methods like #count is called.
This issue is affecting Rails 4.1.x and 4.2.x as well.
The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:
- `attribute`
- Lazy (the attribute will be defined after the schema has loaded)
- Allows either a type object or a symbol
- `define_attribute`
- Runs immediately (might get trampled by schema loading)
- Requires a type object
This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).
Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to
`sum_id`. This means the type returned by the adapter will be at the key
`"SUM(the_column)"`. Longer term, we should eventually be able to retain
type information from the AR::Base subclasses used in joined queries
There exists some other test files that load :minivans fixtures but don't load :speedometers.
Loading :speedometers here prevents the following error when this test was run after such test:
CalculationsTest#test_should_group_by_association_with_non_numeric_foreign_key:
ActiveRecord::RecordNotFound: Couldn't find all Speedometers with 'speedometer_id': (ABC, s1) (found 1 results, but was looking for 2)
The column name given by the adapter doesn't include the table
namespace, so going through the hashed version of the result set causes
overridden keys.
Fixes#15649
With ActiveRecord::Properties, we now have a reasonable path for users
to continue to keep this behavior if they want it. This is an edge case
that has added a lot of complexity to the code base.
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.
For PG adapters with custom expression and grouped result
of aggregate functions have not found correct column type
for it. Extract column type from query result.
Closes: #13230
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*
We moved more and more away from passing options to finder / calculation
methods. The `:distinct` option in `#count` was one of the remaining places.
Since we can now combine `Relation#distinct` with `Relation#count` the option
is no longer necessary and can be deprecated.
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`.
To perform a sum calculation over the array of elements, use to_a.sum(&block).
Please check the discussion in f9cb645dfcb5cc89f59d2f8b58a019486c828c73
for more context.
