# Rails 7.1 "INSERT INTO "schema\_migrations" (version) VALUES" sort order inside db/structure.sql

**URL:** <https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142>\
**Category:** rubyonrails-talk\
**Tags:** migrations\
**Created:** [November 9, 2023, 12:39pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142 "2023-11-09T12:39:21Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jkwuc89](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/jkwuc89/32/1141_2.png) [@jkwuc89](https://discuss.rubyonrails.org/u/jkwuc89)\
**Post date:** [November 9, 2023, 12:39pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/1 "2023-11-09T12:39:21Z")

</div>

My project is set up to use `db/structure.sql` to track database migrations. Prior to Rails 7.1, the order of the rows under `INSERT INTO "schema_migrations" (version) VALUES` was in date ascending order. Snippet from `db/structure.sql` is below.

```ruby
INSERT INTO "schema_migrations" (version) VALUES
 ('20210713133021'),
 ('20210715181117'),
 ('20210716191530'),
 ('20210722210702'),
 ('20210730001905'),
 ('20210804143957'),

```

With Rails 7.1, this order is now in date descending order. Snippet from `db/structure.sql` is below.

```ruby
INSERT INTO "schema_migrations" (version) VALUES
('20231108194548'),
('20231103150202'),
('20231101160730'),
('20231101123237'),
('20231031154044'),

```

Did the sort order change inside Rails 7.1. If so, why?

---

<div class="post-metadata">

**Author:** ![jamiemccarthy](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/jamiemccarthy/32/9347_2.png) [@jamiemccarthy](https://discuss.rubyonrails.org/u/jamiemccarthy)\
**Post date:** [November 12, 2023, 4:19pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/2 "2023-11-12T16:19:46Z")

</div>

It shouldn’t matter.

The data in a table has no intrinsic order. Rows in a table are an unordered set. Order only matters when retrieving or modifying that data, and that order is defined on a query-by-query basis.

(We sometimes think of a table as having the order of its primary key, in this case the `version` column, but this is an operational detail and a mental shortcut, not a feature of the table itself.)

In this case, there is no theoretical difference which order the rows appear in this INSERT query. They could be forwards, backwards, or random; all that matters is that the set of values being inserted is correct. When they’re retrieved with a SELECT, the ORDER BY clause used in that query will be the only thing determining the order (and if there isn’t one, the order is undefined).

---

<div class="post-metadata">

**Author:** ![ghiculescu](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/ghiculescu/32/1145_2.png) [@ghiculescu](https://discuss.rubyonrails.org/u/ghiculescu)\
**Post date:** [November 15, 2023, 7:42am UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/3 "2023-11-15T07:42:10Z")

</div>

It changed in [Reverse the order of `INSERT` statements in `structure.sql` dumps by ghiculescu · Pull Request #44363 · rails/rails · GitHub](https://github.com/rails/rails/pull/44363)

---

<div class="post-metadata">

**Author:** ![jkwuc89](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/jkwuc89/32/1141_2.png) [@jkwuc89](https://discuss.rubyonrails.org/u/jkwuc89)\
**Post date:** [November 15, 2023, 5:11pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/4 "2023-11-15T17:11:47Z")

</div>

Thanks for the PR link Alex.

---

<div class="post-metadata">

**Author:** ![ridiculous](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/ridiculous/32/10524_2.png) [@ridiculous](https://discuss.rubyonrails.org/u/ridiculous)\
**Post date:** [November 15, 2023, 5:50pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/5 "2023-11-15T17:50:46Z")

</div>

So apparently its to address the two line diff from adding a new migration, because of the semicolon… and instead it’s a single line change. I guess that’s better

---

<div class="post-metadata">

**Author:** ![davelnewton](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/davelnewton/32/12279_2.png) [@davelnewton](https://discuss.rubyonrails.org/u/davelnewton)\
**Post date:** [August 13, 2024, 8:32pm UTC](https://discuss.rubyonrails.org/t/rails-7-1-insert-into-schema-migrations-version-values-sort-order-inside-db-structure-sql/84142/6 "2024-08-13T20:32:01Z")

</div>

The difference is convenience, not technical.

Now you can’t just tail the file or jump to the bottom to look for/at a migration conflict.

I’d rather endure changing a few characters while being forced to interact w/ a migration conflict–simple sanity check, too.

Reverse-chronological doesn’t make sense to me here, and it seems a pretty arbitrary tossing of a Rails convention mostly since Rails 🤷‍♂️
