> I think something like that addresses @derekprior's concerns

Yes. I think I like that approach.

> while also being consistent with our practices.

I've always interpreted that practice to mean to not depend on external objects in a migration. Doing so could prevent the migration from running if those objects change. However, I can absolutely depend on the state of the database and if the introduction of AR depends only on the state we know to be available at the time of the migration and makes the migration simpler, then I don't see it as a problem, but a benefit.

That said, this migration breaks the rules I just laid out. It's not necessarily the case that `Clearance::User` will always exist and it's not always the case that the AR interface (or database interface) I have exposed will be enough to satisfy its requirements.

The migration @croaky proposes has similar issues - `Clearance::Tokens` could go away or it could change such that type in use here is not sufficient for what we're storing. I think making it a public, first class Object in the system makes that less likely to be the case though.

If we could generate sufficiently random tokens in pure SQL, that would be the best solution, but I don't see a way to do that without specifically handling each database backend.