| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| | |
`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
|
| | | |
|
|/ /
| |
| |
| | |
Passing conditions to `#destroy_all` was deprecated in c82c5f8.
|
|\ \
| | |
| | |
| | | |
connection adapters column, delegation in Active Record have not use …
|
| |/
| |
| |
| |
| | |
‘set’
found these commits https://github.com/rails/rails/commit/9cc8c6f3730df3d94c81a55be9ee1b7b4ffd29f6, https://github.com/rails/rails/commit/9d79334a1dee67e31222c790e231772deafcaeb8 that also should remove it.
|
| |
| |
| |
| |
| |
| | |
where clause predicate. Get a 3-4% improvement in AST generation.
Perf compare: https://gist.github.com/vipulnsward/7e4e9ecb157e574002313249a7969c82
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 04ac5655be91f49cd4dfe2838df96213502fb274 I assumed that we would
never want to pass the "table_name.column_name" form to where with a
symbol. However, in Ruby 2.2 and later, you can quote symbols using the
new hash syntax, so it's a semi-reasonable thing to do if we want to
support the dot notation (which I'd rather deprecate, but that would be
too painful of a migration).
Instead we've changed the definition of "this is a table name with a
dot" to when the value associated is a hash. It would make very little
sense to write `where("table_name.column_name": { foo: :bar })` in any
scenario (other than equality for a JSON column which we don't support
through `where` in this way).
Close #24514.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue occured because associations now call `where` directly, and a
dot in the key name for `where` means nested tables. For this fix, we
now pass the table name as a symbol, and do not attempt to expand
symbols containing a dot.
This is a temporary fix. I do not think we should support table names
containing a dot, as it has a special meaning in most backends, as well
as most APIs that involve table names. This commit does not include a
test, as I am going to deprecate table names containing dots in the
following commit.
Fixes #24367
|
|
|
|
| |
We should use #find_or_initialize_by and #find_or_create_by because #first_or_initialize and #first_or_create methods are not the public API
|
|\
| |
| |
| | |
Add option to error on ignored order or limit
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ignored in batches
add some documentation and add 4 tests regarding error vs. warning behavior
fix a typo when referring to the message
go back to default in tests so that ordering is not important. use a constant instead of method. fix assert_nothing_raised call. use self.klass to allow per class configuration
remove logger warn assets as that is tested elsewhere. pass error_on_ignore through find_each and find_in_batches also.
add blocks to the finds so that the code is actually executed
put the setting back to default in an ensure
Add a changelog entry
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Delegation of some `Array` methods was removed in commit 9d79334. That
change did add explicit delegation of a few methods that `Array` has but
which aren't on `Enumerable`. However, a few non-mutation methods were
omitted. This adds `Array` delegation of `#in_groups`, `#in_groups_of`,
`#shuffle` and `#split`. This allows things like
`MyThing.all.in_groups_of(3) { ... }` to continue working as they did
before commit 9d79334.
|
|\ \
| | |
| | |
| | |
| | | |
phuibonhoa/phuibonhoa/polymorphic_where_multiple_types
Fixed `where` for polymorphic associations when passed an array containing different types.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
different types.
When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))
This is fixed to properly look for any records matching both type and id:
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
AR::Relation#or
- Previously it used to show error message
<"undefined method `limit_value' for {:title=>\"Rails\"}:Hash">
- Now it shows following error message.
>> Post.where.not(name: 'DHH').or(name: 'Tenderlove')
ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead.
- Fixes #23714.
|
| | |
|
|\ \
| | |
| | | |
Fix AR::Relation#last bugs instroduced in 7705fc
|
| | |
| | |
| | |
| | | |
instead of loading the relation into memory
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes the following warnings.
```
activerecord/lib/active_record/relation/finder_methods.rb:252: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:258: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:268: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:274: warning: ambiguous first argument; put parentheses or a space even after `-' operator
```
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.
|