find_in_batches
- 1.0.0
- 1.1.6
- 1.2.6
- 2.0.3
- 2.1.0
- 2.2.1
- 2.3.8
- 3.0.0 (0)
- 3.0.9 (-5)
- 3.1.0 (0)
- 3.2.1 (0)
- 3.2.8 (0)
- 3.2.13 (0)
- 4.0.2 (16)
- 4.1.8 (35)
- 4.2.1 (0)
- 4.2.7 (0)
- 4.2.9 (0)
- 5.0.0.1 (38)
- 5.1.7 (15)
- 5.2.3 (0)
- 6.0.0 (0)
- 6.1.3.1 (9)
- 6.1.7.7 (0)
- 7.0.0 (0)
- 7.1.3.2 (30)
- 7.1.3.4 (0)
- What's this?
find_in_batches(start: nil, finish: nil, batch_size: 1000, error_on_ignore: nil)
public
Yields each batch of records that was found by the find options as an array.
Person.where("age > 21").find_in_batches do |group| sleep(50) # Make sure it doesn't get too crowded in there! group.each { |person| person.party_all_night! } end
If you do not provide a block to #find_in_batches, it will return an Enumerator for chaining with other methods:
Person.find_in_batches.with_index do |group, batch| puts "Processing group ##{batch}" group.each(&:recover_from_last_night!) end
To be yielded each record one by one, use #find_each instead.
Options
-
:batch_size - Specifies the size of the batch. Defaults to 1000.
-
:start - Specifies the primary key value to start from, inclusive of the value.
-
:finish - Specifies the primary key value to end at, inclusive of the value.
-
:error_on_ignore - Overrides the application config to specify if an error should be raised when an order is present in the relation.
Limits are honored, and if present there is no requirement for the batch size: it can be less than, equal to, or greater than the limit.
The options start and finish are especially useful if you want multiple workers dealing with the same processing queue. You can make worker 1 handle all the records between id 1 and 9999 and worker 2 handle from 10000 and beyond by setting the :start and :finish option on each worker.
# Let's process from record 10_000 on. Person.find_in_batches(start: 10_000) do |group| group.each { |person| person.party_all_night! } end
NOTE: It’s not possible to set the order. That is automatically set to ascending on the primary key (“id ASC”) to make the batch ordering work. This also means that this method only works when the primary key is orderable (e.g. an integer or string).
NOTE: By its nature, batch processing is subject to race conditions if other processes are modifying the database.
When dealing with has_many through
The non-repeating primary key id must be used with find_in_batches.
-
User has many things
-
User has many socks through things
-
Sock has many things
-
Sock has many users through things
For the sake of argument, assume the first user has two socks and all other users have one sock. There are 1000 users in total and 1001 socks in total.
User.joins(:socks).count => 1001 agg = [] # Incorrect User.joins(:socks).find_in_batches{|g| agg += g} agg.count => 1000 Sock.joins(:users).count => 1001 agg = [] # Correct Sock.joins(:users).find_in_batches{|g| agg += g} agg.count => 1001
Be careful with .select
With 999 people in the table:
Person.select('person.firstname').find_in_batches do |group| group.each { |person| puts person.firstname } end
Will work properly.
But with 1001 people in the table, this will raise “Primary key not included in the custom select clause”. It’s a bit of a time bomb. If you’re writing tests for methods that use this, you won’t see a failure unless you’ve tested with more than records than the default batch size.