| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`in_batches` yields Relation objects if a block is given, otherwise it
returns an instance of `BatchEnumerator`. The existing `find_each` and
`find_in_batches` methods work with batches of records. The new API
allows working with relation batches as well.
Examples:
Person.in_batches.each_record(&:party_all_night!)
Person.in_batches.update_all(awesome: true)
Person.in_batches.delete_all
Person.in_batches.map do |relation|
relation.delete_all
sleep 10 # Throttles the delete queries
end
|
| |
|
|
|
|
| |
favour of `begin_at` value.
|
|
|
|
| |
that complements the `start`parameter to specify where to stop batch processing
|
|
|
|
|
| |
We already validate the keys, so it is better to use the built-in
feature to do this
|
|
|
|
|
|
|
|
|
|
| |
This is no longer required now that we are injecting a type caster
object into the Arel table, with the exception of uniqueness
validations. Since it calls `ConnectionAdapter#type_cast`, the value has
already been cast for the database. We don't want Arel to attempt to
cast it further, so we need to continue wrapping it in a quoted node.
This can potentially go away when this validator is refactored to make
better use of `where` or the predicate builder.
|
|
|
|
|
|
|
| |
Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1
|
|
|
|
|
|
|
| |
Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1
|
|
|
|
|
|
|
| |
Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1
|
|
|
|
|
|
| |
I find that `Specifies the starting point for the batch processing.`
does not give enough information for me to understand what this
parameter actually does.
|
|
|
|
| |
key, not just integer ones, as per @a58cafeb3a86be46849de57481b6644094fb8165
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
`find_in_batches` now returns an `Enumerator`
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/relation/batches.rb
|
| |
| |
| |
| |
| |
| | |
so that it
can be chained with other `Enumerable` methods.
|
| | |
|
|/
|
|
|
| |
find_in_batches
Before this patch find_in_batches raises this error only on second iteration. So you will know about the problem only when you get the batch size threshold.
|
| |
|
|\
| |
| |
| |
| | |
ActiveRecord find_in_batches should work without logger
When I set logger to nil both methods from Batches module find_in_batches or find_each should work anyway.
|
| | |
|
|/
|
|
| |
This lets us do things like call: .find_each.with_index
|
| |
|
|
|
|
| |
recommended
|
| |
|
| |
|
|
|
|
|
| |
Related to 761bc751d31c22e2c2fdae2b4cdd435b68b6d783 and
eb876c4d07130f15be2cac7be968cc393f959c62
|
|
|
|
|
|
|
| |
This reverts commit 761bc751d31c22e2c2fdae2b4cdd435b68b6d783.
This commit wasn't fixing any issue just using the same table for
different models with different primary keys.
|
| |
|
| |
|
|
|
|
|
|
| |
It has been moved to active_record_deprecated_finders.
Use #to_a instead.
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Fixes #2832
|
|\
| |
| | |
Bugfix by stopping find_in_batches using the records after yielding.
|
| |
| |
| |
| |
| |
| | |
Currently if the code that calls .find_in_batches modifies the yielded array in place then .find_in_batches can enter an infinite loop searching with ruby object ids in the database instead of the primary key of records in the database. This happens because it naively assumes the yielded array hasn't been modified before calling #id on the last object in the array. And ruby (1.8 at least) alias' #id to #object_id so an integer is still returned no matter what the last object is.
By moving finding the #id of the last object before yielding the array it means the calling code can do whatever it wants to the array in terms of modifying it in place, and .find_in_batches doesn't care.
|
|/
|
|
| |
This caused that `find_each` was producing extra db call taking all the records from db, and was less efficient than `ActiveRecord::Base#all`.
|
| |
|
| |
|
|
|
|
| |
ActiveRecord::Base.primary_key does.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
select but does not specify the primary key
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|