Entity Framework Config Builder

I work with a legacy Microsoft SQL Server database with many inconsistencies and large tables. When working on a .NET Core API with Entity Framework Core, I had to map tables from the database, which became a long a tedious process. I know there had to be a better way, than writing the configuration by hand. This where I worked to write a small console app to create the config for me.

This app started as a simple ruby script at first. As our team grew I converted it over to a .NET Core console app, so It could be used across our team. The app takes a CSV output of a sp_columns stored procedure from SQL Server database, reads it and outputs the config to the console.

You can check it out here: https://github.com/rebelweb/ConfigBuilder

Your coding skills are your most powerful asset, use them to your advantage. When you face a tedious repetitive task, see if you can write a few lines of code to save hours of time.

Updating My Time Rounding Library

It has been awhile since I have touched the time_rounder gem. When I left off, I only implemented the 15 minute schedule. I have recently started work on that gem again in an effort to commit more to open source and build up my portfolio. Here is what I have been up to with the gem.

First, I have improved the rounding schedule setup. When I started the gem I just simple used large hashes containing every minute of an hour and what it rounded to. I since found a happy medium in using Array’ min_by and a small amount of math. I may make further improvements to the code in future but I feel it is pretty good at the moment.

Next, I have improved the tests and made them easier to understand and not have so many examples by lumping common examples together. I essentially take all the minutes that round to the same number and test them in a loop, instead of repeating a test for each minute of the hour.

Lastly, I am working on the other rounding schedules. At the moment there is only the 15 minute schedule. The plan is to add 1 hour, 30 minute, 20 minute, 10 minute. and 5 minute schedule. Once all the schedules are complete the gem will move to a 1.0 release.

Resetting Rails Counter Cache with ActiveJob

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.