In our app, we have a deeply nested hash called public_data that’s often used to render a record’s JSON payload, along with its associations, in the controller.

This public_data hash is built from a mix of attributes and model methods. However, it also calls the public_data methods of associated models, which might, in turn, call back to the original model’s public_data. This circular complexity has been a challenge, and while we’ve started transitioning to the Barley serializer gem for better structure, we still rely on this method in parts of our codebase for backward compatibility.

So when @user.public_data is called in the controller, it often triggers a long chain of database queries. Tracking down where a specific relation is being called—​whether in User, Profile, or Subscription--can be daunting.

While Rails logs are helpful, they require sifting through the output to correlate the log entry with the SQL query. This becomes even trickier when debugging in remote environments and searching through extensive logs in tools like New Relic or CloudWatch.

Enter ActiveRecord::Relation#annotate…​

This simple method lets you add comments to your SQL queries, embedding contextual information directly within the query.

Here’s how it works:

This provides a clear indication of where the query originated. You can also include additional context, such as the current locale, user, or order ID, depending on your needs.

For example, adding an annotation inside the public_data method on my Subscription model makes it much easier to trace where the query originated in the chain.

Another great feature is the ability to stack annotations. Let’s say we add an annotation in the active scope of the User model:

Calling the same query as before would generate:

Neat, right? This approach brings more clarity and structure to your logs, making them easier to query and group in log viewers. Additionally, these annotations appear in your database logs, offering a seamless way to correlate them with application logs.

Possible applications include:

That said, annotations come with a slight tradeoff in query readability. It’s essential to be deliberate about what and when to log, and to periodically review whether the annotations remain relevant and valuable.

Even if used exclusively for local debugging, SQL annotations are an excellent addition to your toolbox.

Six months later, the Heroku-Kubernetes transition is now over. I have gained a lot of experience. And I feel it’s time to share it.

I have this Caregiver model within a nested form and I need to create it along with a User entity in my form, to be able to populate the fields. The problem is that creating an after_initialize callback (even with :new_record? will break the general behaviour of my app, and I don’t want to run through all the specs and fix FactoryBot issues etc.

So I just decided to create a small method in my Caregiver model:

Then I just need to call it in my view like this:

This makes the code in my view simpler, more explicit, while avoiding the dreaded callback hell.

I recently had to make a semi-complex check on a string to validate it.

Basically, I have this model method which produces a serial number based on the ID of the object. Valid returned values for this method are L00000002, L00000587 or L00014522. In short, they should be constituted of a capital L followed by 8 digits composed of the id of the object padded with zeros.

So I had to find a way to simply created a matcher for this to use in my model spec. I could have built two expectations, one for the length, and one for the composition. But I just decided to believe that regular expressions are powerful enough to do both at the same time. So I headed to rubular and started fiddling and googling around.

The solution I came up with was the following (with an id of 12, for instance):

What this does, is - after the starting ^L character - create a condition matching whatever follows the ?= inside the parentheses. If this condition is true, then the rest of the expression is read. So I just check for any digit ([0-9] - it could have been \d but readability make the first option a better fit IMHO) exacty 8 times ({8}) and then the end of the string with $. If this is matched, then I check any number of zeros (0*) followed by the id (12) and the end of the string ($).

Now I could use this expression in my spec, using the Regexp.escape method on my model’s id within a string interpolation:

Don’t you just love regular expressions?

I am about to release a huge rails project I have been working on for quite a while. This project is meant to replace an old app that manages a database of customers with emails. The new rails project uses Devise for authentication.

Before we push the final update to the production server, we need to find a way to import the users without sending confirmation emails, but still keep them unconfirmed until they actually login to the new system and provide a password. New registrations should also still be confirmable.

So I had to find a way to override an instance method. This is easy to do with a simple module:

What this basically does is alias the send_confirmation_instructions method to a new return_false instance method we can inject into our model like this :

Therefore, my users will still have to confirm their account at first login on the new system, but won’t be notified when I import the database a few days before launch.

This can easily be adapted to serveral use cases, whenever you need to override an instance method in an exisiting Ruby class, as seen in this GitHub gist.