I have recently tried something a little different, when working with Rails counter caches. For those new to rails counter cache columns are where you setup a column to hold a count of a has_many relationship to make a lookup faster than a count SQL query. You can read more about that more about them in the API, Rails Associations
I tried setting up resetting counter caches in ActiveJob, instead of using a rake task to do so. Use case for this would be when someone updates the count from SQL or when you first implement the counts. This would allow me to call the job from the admin interface of my application, I still can call the job from a rake task if I needed to. Lets take a closer look:
I started thinking how to do this efficiently without minimal coding. I started digging to see how to turn snake case into a class name, so I take something like category and turn it into Category. I know the generators that come baked into Rails work this way, so I searched the Rails repository on github, to see how it works and used it in this example.
The update script uses a JSON file to store the class and the relating relationships that need updated. It is structured with the class name in snake case as the key, and the value of an array of all the relationships needing updated. See the example below.
Now for the job code (see below). The job accepts one parameter which is the key. The key is the key from the JSON file discussed earlier so you can do all tables or just a single table, to allow for maximum flexibility, or concurrency since we are using Active Job. To use concurrency simple spin each class in its own job. The job loads the JSON file storing the configuration, and depending on if a key was passed it will loop through all keys and columns or just the one specified.
For the actual business end of things the update_cache_columns method does the brunt of the work. The method takes the key and turns it into a class_name, and updates each one of it’s cache columns.
Testing this is easy. First, we’ll create the related object and update the count via raw SQL. Then we’ll finally run the job and verify it updated the count successfully.
I am including my base model code, to help any one see how a counter cache is setup. The category relation on ArticleCategory contains counter_cache: :articles_count, which is what typically updates the column in the category table every time one is created or destroyed. The job above is for when the counts are wrong due to something going a rye.
This is a different spin on how this is typically handled. I welcome any thoughts on this implementation.