| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \
| | | |
| | | |
| | | |
| | | | |
kamipo/finder_bang_method_should_call_non_bang_method
Finder bang method should call non bang method
|
| | |/
| |/|
| | |
| | | |
Otherwise CollectionProxy's bang methdos cannot respect dirty target.
|
|\ \ \
| | | |
| | | |
| | | | |
Extract `PredicateBuilder::CaseSensitiveHandler`
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Currently uniqueness validator is coupled with building Arel ASTs.
This commit extracts `PredicateBuilder::CaseSensitiveHandler` for
decouple the building Arel ASTs.
|
|\ \ \
| | | |
| | | |
| | | | |
Fix count which would sometimes force a DISTINCT
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current behaviour of checking if there is a LEFT OUTER JOIN arel
node to detect if we are doing eager_loading is wrong. This problem
wasn't frequent before as only some pretty specific cases would add
a LEFT OUTER JOIN arel node. However, the recent new feature
left_outer_joins also add this node and made this problem happen
frequently.
Since in the perform_calculation function, we don't have access to
eager_loading information, I had to extract the logic for the distinct
out to the calculate method.
As I was in the file for left_outer_join tests, I fixed a few that had
bugs and I replaced some that were really weak with something that
will catch more issues.
In relation tests, the first test I changed would have failed if it
had validated the hash returned by count instead of just checking how
many pairs were in it. This is because this merge of join currently
transforms the join node into an outer join node, which then made
count do a distinct. So before this change, the return was
{1=>1, 4=>1, 5=>1}.
|
|/ /
| |
| |
| |
| |
| | |
If handled as an associated predicate even though a table has the
column, will generate invalid SQL by valid column name treated as a
table name.
|
|\ \
| | |
| | |
| | | |
Make association queries to preparable: Step 1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently association queries cannot be preparable.
```ruby
Post.where(author_id: 1).to_a
# => SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = ? [["author_id", 1]]
Post.where(author: 1).to_a
# => SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 1
```
To make association queries to preparable, it should be handled in
`create_binds_for_hash`. This change is a first step for it.
|
|\ \ \
| | | |
| | | | |
`where` by `array|range` attribute with array or range value
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
Currently predicate builder cannot build a predicate for `array|range`
attribute. This commit fixes the issue.
Related #25671.
|
|\ \ \
| | | |
| | | | |
When calling association.find RecordNotFound is now raised with the s…
|
| |/ /
| | |
| | |
| | | |
argument as when we do it in Record.find (primary_key, id and model).
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| | |
| | |
| | |
| | |
| | |
| | | |
`find_nth` is protected method, therefore `offset` has not been passed
anywhere. `find_nth_with_limit_and_offset` is unnecessary anymore
because `offset` has not been passed.
|
|\ \ \
| |/ /
|/| | |
add more array methods to straight delegation to speed up calling them
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
| |
| |
| | |
Some case expressions remain, need to think about those ones.
|
|\ \
| | |
| | | |
`ActiveRecord::PredicateBuilder#expand` to be private
|
| | |
| | |
| | |
| | | |
This method is not touched from outside.
|
|/ / |
|
|\ \
| | |
| | | |
Revert passing arel node with splat binds for `where`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Passing arel node with splat binds for `where` was introduced at #22877
for uniqueness validator supports prepared statement. But I'd not like
to introduce the following usage:
```ruby
Foo.where(arel, *binds)
```
I'd like to revert this internal usage.
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\
| |
| | |
`FinderMethods` uses `records` (`load_target`) when `loaded?` is true
|
| | |
|
|/ |
|
|
|
|
|
| |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
| |
|
|
|
|
|
| |
We are setting a limit unconditionally just below,
which overrides any existing one anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|\
| |
| | |
Prevent `RangeError` for `FinderMethods#exists?`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`FinderMethods#exists?` should return a boolean rather than raising an
exception.
`UniquenessValidator#build_relation` catches a `RangeError` because it
includes type casting due to a string value truncation. But a string
value truncation was removed at #23523 then type casting in
`build_relation` is no longer necessary. aa06231 removes type casting in
`build_relation` then a `RangeError` moves to `relation.exists?`.
This change will remove the catching a `RangeError`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`construct_relation_for_association_calculations` pass a string value to
`construct_join_dependency` when setting a string value in `from`.
It should not pass a string value, but always `joins_values`.
Related #14834, #19452.
Fixes #24193.
|
|/ |
|
|\
| |
| | |
Reuse a result of `table.associated_table(column)` in `AssociationQueryHandler.value_for`
|
| |
| |
| |
| | |
`AssociationQueryHandler.value_for`
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `exists?` does some hackery where it assumes that we can join
onto anything that we passed to `eager_load` or `includes`, which
doesn't work if we are joining onto a polymorphic association.
Actually figuring out if we want to include something would require
knowledge deep within the join dependency module, which is hard to pull
up. The simplest solution is just to pass a flag down that says we're
not actually going to try to eager load any of the data. It's not the
solution I'd like, but that code really needs to be untangled before we
can do much with it.
This is another attempt at 6d5b1fd which should address the concerns
that led to reverting it in 4ecabed.
|
|
|
|
| |
`association_for_table` is unused since 50a8cdf.
|
|
|
|
|
|
|
|
| |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
|\
| |
| | |
Forward ActiveRecord::Relation#count to Enumerable#count if block given
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 5.0 we use bind parameters for limit and offset, while in 4.2 we used
the values directly. The code as it was written assumed that limit and
offset worked as `LIMIT ? OFFSET ?`. Both Oracle and SQL Server have a
different syntax, where the offset is stated before the limit. We
delegate this behavior to the connection adapter so that these adapters
are able to determine how the bind parameters are flattened based on
what order their specification has the various clauses appear.
Fixes #24775
|
|\ \
| | |
| | | |
delegate encode_with instead of to_yaml, which is deprecated
|