Welcome to another edition of This Week in #dev, a series of posts where we bring some of the most interesting Slack conversations to the public.
Sequence Incrementing on Postgres
A couple weeks prior, Sara Jackson shared some information about why FactoryBot-generated objects have perpetually incremented IDs across multiple runs of a test suite: PostgreSQL auto-increments primary keys (IDs) based on a sequence that is created along with the table; it doesn’t matter if the object was used just once, or for a test, or deleted – if your DB isn’t reset/cleaned, the sequence still keeps track. (She also shared an article about how to know if you’re running out of IDs and what to do about it.)
Building on this knowledge, Elias and Summer ☀️ pointed out that on Postgres, when attempting to insert a row and it fails due to an unmet constraint, the sequence will still be incremented. Matheus shares the link for the Postgres documentation on the subject.
To avoid blocking concurrent transactions that obtain numbers from the same sequence, the value obtained by
nextval` is not reclaimed for re-use if the calling transaction later aborts. This means that transaction aborts or database crashes can result in gaps in the sequence of assigned values. That can happen without a transaction abort, too.
Active Record’s inverse_of
Rémy encountered the inverse_of option in Active Record associations and was
unsure of its purpose. After some research, he found out it has two main
purposes:
- Avoiding an extra query when fetching the record in the belongs_to direction
- Helping with acceptsnestedattributes_for when creating an object and its children.
Thanks
This edition was brought to you by Elias Rodrigues, Summer ☀️, Matheus Richard, Sara Jackson, and Rémy Hannequin. Thanks to all contributors! 🎉
