Previous posts in the series:
Part 1: Introduction
Part 2: Transactions and Save Points

So far, GORM has helped us abstract our data-access logic and removed the need to write SQL queries directly, but is everything perfect? In this post, I will cover some of the pitfalls I’ve noticed and advise on how to avoid them.

Modeling
With GORM, it is common to use the Model() function when updating existing records. This is because it removes the need to specify the table name, the primary key, and possibly other arguments.

This will generate the wanted SQL query to make the update as intended:

But now, what will happen if the “User” object is set on the bill?
Let’s change the code to preload the user object to find out.

With this example, the generated SQL queries will look like this:

Wait. What? It looks like GORM is trying to create the User object as it is associated with the bill object. This is a typical pitfall developers usually miss, as this is a side-effect that is not always intended. In this example, no harm is done as we have the user, and nothing changed, but you may model objects with other details that may accidentally create new objects or modify existing ones.

One thing to prevent this from happening is to omit all associations when using GORM with any mutating operations (INSERT, UPDATE, DELETE). The updated, relevant piece of code will look like this:

Furthermore, it gets even more interesting when you are updating multiple records. Assuming I have a few bills (not necessarily related to the same user), I want to update their due date. My tables look like this:

Now, let’s have the following piece of code to update the due date of all the overdue bills.

The generated SQL queries will look like this:

That’s interesting, right? I expected two updates, but instead, I got only 1 row. The reason is that GORM is not intelligent enough to complain that although I am using Find() and there are more than one record that matches the condition, I passed a single Bill variable, not a slice.

Practical Advice: In case I am passing “real” objects into GORM to generate some mutating operations on my data, I always use Omit(clause.Associations)

Tip: Always have some logging or metrics around these things so you can monitor your program and find such issues. It is also a good practice to have unit tests that test calls with multiple records.

After fixing the code to have a slice of bills, the result is as expected:

So GORM is smart enough to combine multiple updates into a single UPDATE clause. Let’s make it more interesting by preloading the bill associations before calling updates.

The generated SQL queries will look like this:

So GORM is trying to create the users and then updates the bill’s due date as expected. We already know that the attempt to create the users is due to the object associations that GORM tries to resolve. But now comes the more exciting part, what if I change Updates() to UpdateColumn() ?

At this stage, another weird thing happened, and the generated SQL queries look like this:

For some reason, GORM decided to update the user_id of both items (in addition to their due date) and linked both bills to the same user !!! This is a severe issue and an actual data corruption caused by GORM.

As before, omitting associations solves the problem, and by adding it, the generated SQL query will be:

Practical Advice: Using Model() with your actual objects is dangerous, and I would advise against using it unless you know what you are doing. Instead, I would be more explicit and use Table() and Where() functions.

Note: More information regarding GORM handling of associations, can be found in the official documentation.

Idempotency

When creating records in the database, we usually have an idempotency rule different from the primary key. For example, we don’t want more than one user with the same first and last name. GORM allows us to do so by using the FirstOrCreate function. For example, let’s look at the following code:

The generated SQL query is far from what I wanted it to be:

GORM assumed I didn’t have any search criteria, so it returned the first record from the Users table, sorted by UUID. Because the table has some users, no “Alexander Sirotin” was created.

What would happen if I also initialize the {UUID: “something”} within the User object? Let’s see:

Huh. So GORM will attempt to use the primary key of the passed object (in this case, the user’s UUID) as the matcher. There was no match on the user.UUID = “something” so GORM created the user.

To fix it and be able to specify exactly the fields you want, you need to be more explicit and pass the condition as the second argument to FirstOrCreate, or use the Where() function:

And the generated SQL query will look like this:

Practical Advice: Always be explicit in your queries and don’t use a “real” object, but instead construct the objects you need for the query or use specific columns by name. The reason is the “user” object I pass to the Where() function might come from a different place in the code that can load other attributes into it, changing my idempotency criteria.

– Alexander

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive a notification when new posts are published!

We don’t spam!

Check your inbox or spam folder to confirm your subscription.