Support ActiveRecord::Batches::BatchEnumerator collections

[adrianna-chang-shopify]

Closes: #390, #401

This PR allows users to specify batch collections via the following API:

# app/tasks/maintenance/update_posts_in_batches_task.rb
module Maintenance
  class UpdatePostsInBatchesTask < MaintenanceTasks::Task
    def collection
      Post.in_batches
    end

    def count
      collection.count
    end

    def process(batch_of_posts)
      batch_of_posts.update_all(content: "New content added on #{Time.now.utc}")    
    end
  end
end

Users are expected to use #in_batches. We use EnumeratorBuilder#active_record_on_batch_relations under the hood to build an enumerator that yields ActiveRecord::Relations - we get the ActiveRecord collection via @relation and the batch size via@of on the Batch Enumerator.

I've also tweaked Ticker#tick to take an increment, defaulting to 1. In TaskJob#each_iteration, I've tweaked the call to #tick to use input.size if input is_a?(ActiveRecord::Relation). This makes it so that tick count is still based on the number of records, rather than the number of batches, if we're processing batches.

[adrianna-chang-shopify]

@etiennebarrie I've requested your review on this. CI obviously fails because the Job Iteration changes haven't shipped yet, but tests pass with the changes from Shopify/job-iteration#86.

Hoping for another review on the Job Iteration PR from Job Patterns. In the meantime, I figured there was no reason to wait on getting feedback on this 😄

[etiennebarrie]

use input.size if input is_a?(ActiveRecord::Relation).

I'm not so sure about this one, that will cause an additional COUNT query for each iteration, even if we don't use the increment because the last ticker update was recent enough.

Inside each_iteration, the relation is a batch relation right? So its number of elements should be equal to the batch size most of the time, and smaller for the last batch, maybe we could use that instead?

[adrianna-chang-shopify]

I'm not so sure about this one, that will cause an additional COUNT query for each iteration, even if we don't use the increment because the last ticker update was recent enough.

I think we're actually okay here - when we call ActiveRecordCursor#next_batch, we do:
update_from_record(records.last) unless records.empty?. Naturally, #exists? loads the relation - so by the time we get to calling input.size in each_iteration, that relation should already be loaded, and shouldn't do another COUNT query.

I actually implemented it using just the batch size as you'd suggested initially, but then I moved away from that because the margin of error can be pretty big - if your batch size is 1000 and you have 1003 records to process, your final tick count will be 2000, which is weird.

I think we should be good with using #size instead, since this won't actually result in a SQL query.

[etiennebarrie]

Hum, previously the records.empty? wouldn't have caused any additional query though because the records were loaded already. Since we're going to need at least one query to get the last record, I think we could change that to:

last_record = records.last
update_from_record(last_record) if last_record

or change update_from_record to early return if given nil.

Today it's one query to load the records (in job-iteration) + one query for updating them (in the app code).
E.g. records = relation.to_a + Post.where(id: posts.map(&:id)).update_all(published: true).

Ideally we'd move to one query to get the next cursor value + the app code.
relation.pluck(@columns) or something in job_iteration + relation.update_all(published: true).

Hopefully even if it doesn't help much with the SQL, it helps by not loading so much stuff in memory?

[adrianna-chang-shopify]

cc @Shopify/rails @Shopify/core-stewardship

[adrianna-chang-shopify]

cc @etiennebarrie

[etiennebarrie]

Some more wording propositions, feel free to tweak. The rest is great 🎉

[lamp]

Thank you so much for this! 😃