# Unintuitive migration order when extra digits in timestamp

**URL:** https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678
**Category:** Issues
**Created:** [March 4, 2025, 1:32pm UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678 "2025-03-04T13:32:51Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![vizvamitra](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.rom-rb.org/vizvamitra/32/332_2.png) [@vizvamitra](https://discourse.rom-rb.org/u/vizvamitra)
#### Post date: [March 4, 2025, 1:32pm UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678/1 "2025-03-04T13:32:51Z")

</div>

Hi community,

Several months ago we’ve created a migration with an extra digit in it’s timestamp. Not a big deal for prod, so we haven’t noticed it for 4 months. But recently I added another migration that changes the same stuff, and `rake db:drop db:create db:migrate` started failing. Investigation showed that ROM applies migrations with extra digit in the timestamp after all the rest.

I’m not sure if it is a bug or not, but it’s definitely unintuitive and may cause issues. And it is not hard at all to get one or two such migrations in your project throughout it’s lifetime. We had 3 actually. I guess some other projects that use rom-sql also have such. Would be nice if `db:migrate` at least produce a warning in such cases

You can reproduce this behavior with the following files:

```ruby
# Gemfile
source "https://rubygems.org"

gem "rom"
gem "rom-sql"
gem "rake"
gem "sqlite3"

```

```ruby
# Rakefile
ENV["BUNDLE_GEMFILE"] ||= File.expand_path("./Gemfile", __dir__ )

require "bundler/setup"
Bundler.require

require 'rom/sql/rake_task'

namespace :db do
  task :setup do
    ROM::SQL::RakeSupport.env = ROM::Configuration.new(:sql, "sqlite://dev.db")
  end
end

```

```ruby
# db/migrate/200011223344559_invalid_timestamp.rb
# ^
ROM::SQL.migration do
  change { puts "Migration with extra digit in timestamp" }
end

```

```ruby
# db/migrate/20251122334455_valid_timestamp.rb
ROM::SQL.migration do
  change { puts "Migration with valid timestamp" }
end

```

```bash
rake db:migrate
# =>
# Migration with valid timestamp
# Migration with extra digit in timestamp
# <= db:migrate executed

```

---

<div class="post-metadata">

### Author: ![katafrakt](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.rom-rb.org/katafrakt/32/275_2.png) [@katafrakt](https://discourse.rom-rb.org/u/katafrakt)
#### Post date: [March 7, 2025, 10:26am UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678/2 "2025-03-07T10:26:54Z")

</div>

The first component of the migration file name is not a timestamp. It’s an order number. Using a timestamp for that is just convenience to have files ordered in the ascending order in the filesystem listing and to carry additional information.

By adding extra digits you just created much larger number, so the migration is applied last. It would work the same way in Rails, Ecto and probably other frameworks with migrations.

---

<div class="post-metadata">

### Author: ![vizvamitra](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.rom-rb.org/vizvamitra/32/332_2.png) [@vizvamitra](https://discourse.rom-rb.org/u/vizvamitra)
#### Post date: [March 7, 2025, 10:57am UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678/3 "2025-03-07T10:57:05Z")

</div>

Thank you for your comment, but I believe it may be not correct. Sequel has two migratiors: `IntegerMigrator` (works as you’ve said) and `TimestampMigrator` that works with timestamps in migration names:

> The `TimestampMigrator` will be used if any filename in the migrations directory has a version greater than 20000101

> With the `TimestampMigrator`, the version integer should represent a timestamp, though this isn’t strictly required  
> […]
> 
> `# Date`  
> `20100510_create_artists.rb`
> 
> `# Date and Time`  
> `20100510120000_create_artists.rb`
> 
> `# Unix Epoch Time Integer`  
> `1273518000_create_artists.rb`

([Sequel documentation](https://github.com/jeremyevans/sequel/blob/master/doc/migration.rdoc#timestampmigrator-filenames-) on that)

Actually, after writing this I’ve realized that I should’ve open an issue in Sequel rather than here 😅

---

<div class="post-metadata">

### Author: ![katafrakt](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.rom-rb.org/katafrakt/32/275_2.png) [@katafrakt](https://discourse.rom-rb.org/u/katafrakt)
#### Post date: [March 7, 2025, 11:26am UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678/4 "2025-03-07T11:26:54Z")

</div>

I might be wrong, but I think ultimately the `TimestampMigrator` still [treats these pre-underscore values as integers](https://github.com/jeremyevans/sequel/blob/master/lib/sequel/extensions/migration.rb#L809). It expects the timestamps to all have the same format:

> The important thing is that all migration files should be in the same format, otherwise when you update, it’ll be difficult to make sure migrations are applied in the correct order, as well as be difficult to unapply some the affected migrations correctly.

But I understand the expectation and confusion, because the existence of `TimestampMigrator` would suggest something else.

---

<div class="post-metadata">

### Author: ![vizvamitra](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.rom-rb.org/vizvamitra/32/332_2.png) [@vizvamitra](https://discourse.rom-rb.org/u/vizvamitra)
#### Post date: [March 7, 2025, 11:39am UTC](https://discourse.rom-rb.org/t/unintuitive-migration-order-when-extra-digits-in-timestamp/678/5 "2025-03-07T11:39:19Z")

</div>

I’ve created a discussion in Sequel’s github regarding this: [Unintuitive migration order when extra digits in timestamp · jeremyevans/sequel · Discussion #2284 · GitHub](https://github.com/jeremyevans/sequel/discussions/2284)

As for us, we’re going to use a pre-commit hook for now to prevent committing invalid migrations in the future
