| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
|/ /
| |
| |
| | |
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.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9f3730a516f30beb0050caea9539f8d6b808e58a, reversing
changes made to 2637fb75d82e1c69333855abd58c2470994995d3.
There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.
|
|
|
|
| |
instead of loading relation
|
|\
| |
| | |
Consistently warn that passing an offset to `find_nth` is deprecated
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
@bogdan pointed out that a `loaded?` relation would not warn that the supplied
offset would be removed. This fixes that oversight.
https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834
Although this second argument is probably not widely used, and would be
ignored anyway in the loaded? case, this could protect callers from gotchas.
[Ben Woosley & Victor Kmita]
|
| |
| |
| |
| |
| | |
Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a similar case to wanting ot use bind params for limit and
offset. Right now passing a range grows the amount of prepared
statements in an unbounded fashion. We could avoid using prepared
statements in that case, similar to what we do with arrays, but there's
a known number of variants for ranges.
This ends up duplicating some of the logic from Arel for how to handle
potentially infinite ranges, and that behavior may be removed from Arel
in the future.
Fixes #23074
|
| |
| |
| |
| |
| |
| | |
instead of start_at/end_at based on comments
at https://github.com/rails/rails/pull/12257#issuecomment-74688344
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code that set the from clause was removed in
bdc5141652770fd227455681cde1f9899f55b0b9. I did not give any reason for
doing so. My assumption was that I intended to change it to use the
clause objects, but forgot. We appeared to not have test coverage for
this case.
Fixes #22996
|
| |
| |
| |
| |
| |
| |
| |
| | |
When you are using scopes and you chaining these scopes it is hard to
know which are the values that are incompatible. This way you can read
the message and know for which values you need to look for.
[Herminio Torres]
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 5d41cb3bfd6b19833261622ce5d339b1e580bd8b.
This implementation does not properly handle cases involving predicates
which are not associated with a bind param. I have the fix in mind, but
don't have time to implement just yet. It will be more similar to #22823
than not.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While the predicates are an arel equality node where the left side is a
full arel attribute, the binds just have the name of the column and
nothing else. This means that while splitting the predicates can include
the table as a factor, the binds cannot. It's entirely possible that we
might be able to have the bind params carry a bit more information (I
don't believe the name is used for anything but logging), and that is
probably a worthwhile change to make in the future.
However the simplest (and likely slightly faster) solution is to simply
use the indices of the conflicts in both cases. This means that we only
have to compute the collision space once, instead of twice even though
we're doing an additional array iteration. Regardless, this method isn't
a performance hotspot.
Close #22823.
[Ben Woosley & Sean Griffin]
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Refactor `case_{sensitive|insensitive}_comparison`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```
SELECT 1 AS one FROM "topics" WHERE "topics"."title" = 'abc' LIMIT $1 [["LIMIT", 1]]
```
After:
```
SELECT 1 AS one FROM "topics" WHERE "topics"."title" = $1 LIMIT $2 [["title", "abc"], ["LIMIT", 1]]
```
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I realized that `first(2)`, etc. was unnecessarily querying for the
records when they were already preloaded. This was because
`find_nth_with_limit` can not know which `@records` to return because
it conflates the `offset` and `index` into a single variable, while
the `@records` only needs the `index` itself to select the proper
record.
Because `find_nth` and `find_nth_with_limit` are public methods, I
instead introduced a private method `find_nth_with_limit_and_offset`
which is called internally and handles the `loaded?` checking.
Once the `offset` argument is removed from `find_nth`,
`find_nth_with_limit_and_offset` can be collapsed into
`find_nth_with_limit`, with `offset` always equal to `offset_index`.
|
|
|
|
|
|
|
|
| |
All uses of the `offset` are passing `offset_index`. Better to push
down the `offset` consideration into `find_nth`.
This also works toward enabling `find_nth_with_limit` to take
advantage of the `loaded?` state of the relation.
|
|\
| |
| |
| | |
ActiveRecord::Base#find(array) returning result in the same order as the array passed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We know the query will return exactly one row for each entry in the
`ids` array, so we can do all the limit/offset calculations on that
array, in advance.
I also split our new ordered-ids behaviour out of the existing
`find_some` method: especially with this change, the conditionals were
overwhelming the actual logic.
|
| |
| |
| |
| | |
@values hash
|
| |
| |
| |
| | |
.find(array) with offset
|