| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Users should pass strings to queries instead of classes
|
|
|
|
| |
key, not just integer ones, as per @a58cafeb3a86be46849de57481b6644094fb8165
|
|
|
|
|
|
|
|
|
|
| |
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]
|
|\
| |
| | |
Refactor `PredicateBuilder` from singleton to instance
|
| | |
|
|/
|
|
|
|
| |
This commit fixes the following case.
User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)
|
|
|
|
|
| |
`where_sql` now requires that we pass it an engine. None of the manager
classes take an engine in their constructor.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We never actually make use of it on the table, since we're constructing
the select manager manually. It looks like if we ever actually were
grabbing it from the table, we're grossly misusing it since it's meant
to vary by AR class.
Its existence on `Arel::Table` appears to be purely for convenience
methods that are never used outside of tests. However, in production
code it just complicates construction of the tables on the rails side,
and the plan is to remove it from `Arel::Table` entirely. I'm not
convinced it needs to live on `SelectManager`, etc either.
|
| |
|
|
|
|
| |
on the joined assoiciation
|
| |
|
|
|
|
| |
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
|
|
|
|
|
| |
We should not behave differently just because a class has a default
scope.
|
|
|
|
|
|
| |
Arel specifically handles `SelectManager`, with the same logic we're
currently performing. The AST is `Enumerable`, which Arel looks for
separately now.
|
| |
|
|
|
|
|
|
| |
We need to re-order the bind parameters since the AST returned by the
relation will have the where statement as the first bp, which breaks on
PG.
|
|
|
|
|
| |
MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
|
|
|
|
|
| |
We end up re-ordering them either way when we construct the Arel AST (in order
to deal with rewhere, etc), so we shouldn't bother giving it a number in the
first place beforehand.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Passing ranges to `#in` has been deprecated in Arel.
|
|\
| |
| | |
let warn with heredocs
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
|
| |
| |
| |
| | |
The value methods will default to an empty array for us automatically
|
|/
|
|
|
|
|
|
| |
The change to accessing keys directly was originally added to allow
`merge` to take a hash. The implementation of `HashMerger` no longer
requires us to be doing so. Accessing the values directly makes it
impossible to change internal storage details, even if shim methods are
added temporarily
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit removes the duplication of the error message:
> Couldn't find #{@klass.name} with [#{arel.where_sql}]
introduced in #15791 by adding a private method `find_nth!` that
deals with all the method like `first!` and `second!`.
|
|
|
|
|
| |
The hash is now string-keyed, and [_]reflect_on_association calls `to_s` on the
argument anyway.
|
|\
| |
| | |
Update RecordNotFound exception cases to include a message with the
|
| |
| |
| |
| | |
Model that the Record was not found in.
|
| |
| |
| |
| |
| |
| | |
[Matthew Draper & Yves Senn]
Closes #16860. (pull request to discuss the implementation)
|
| |
| |
| |
| |
| |
| |
| |
| | |
`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]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is cased by 03118bc + 9b5d603. The first commit referenced the undefined
local variable `column` when it should be using `reflection.type` as the lookup
key. The second commit changed `build_arel` to not modify the `bind_values` in-
place so we need to combine the arel's `bind_values` with the relation's when
building the SQL.
Fixes #16591
Related #15821 / #15892 / 7aeca50
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.
This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.
|
| |
| |
| |
| | |
Fixes #15821.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the request parameters are passed to create_with and where they can
be used to do mass assignment when used in combination with
Relation#create.
Fixes CVE-2014-3514
Conflicts:
activerecord/lib/active_record/relation/query_methods.rb
|
| |
| |
| |
| |
| |
| | |
Example:
Author.where(posts: { author_id: Author.where(country_id: 1) }).joins(:posts)
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Attempting to reduce the number of places that care about the details of
how type casting occurs. We remove the type casting of the primary key
in `JoinDependecy`, rather than encapsulating it. It was originally
added for consistency with
https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211,
but that conditional was later removed in
https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734.
What is important is that the same row twice will have the same value
for the primary key, which it will.
|
| | |
|