I'm not totally convinced we need to pull in ActiveRecord objects here and still prefer a SQL approach like:

```ruby
users = select_all 'SELECT id FROM users where remember_token IS NULL'

users.each do |user|
  update <<-SQL
    UPDATE users
    SET remember_token='#{Clearance::Tokens.generate}'
    WHERE id=#{user['id']]}
  SQL
end
```

We also create:

```ruby
module Clearance
  class Tokens
    def self.generate
      SecureRandom.hex(20).encode('UTF-8')
    end
  end
end
```

And refactor `Clearance::User` to use `Clearance::Tokens.generate`?

```ruby
def generate_confirmation_token
  self.confirmation_token = Clearance::Tokens.generate
end

def generate_remember_token
  self.remember_token = Clearance::Tokens.generate
end
```

I think something like that addresses @derekprior's concerns while also being consistent with our [practices](https://github.com/thoughtbot/guides/tree/master/best-practices#rails). It is maybe a bit more obvious to the code reader what's happening in their database. I see we're using `find_each` batching in the current PR implementation, but I generally like the speed of just pulling out the integers. For a library, it might be nice to assume the users table could be very large for some Clearance-using developers.

Interested to hear folks' thoughts on whether that's the right kind of coupling between collaborators. `user.reset_remember_token!` is the only existing public interface at the moment.