Unintuitive migration order when extra digits in timestamp

[vizvamitra]

Hi,

In our company we're using ROM.rb. 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. After some investigation, I've found out that Sequel::TimestampMigrator that ROM uses under the hood 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 an unintuitive behavior that may cause issues. It is not hard at all to name one or two migrations incorrectly throughout the project lifespan. Our project is 6 years old and we had 3 actually.

So, I though that maybe Sequel could help users to stick to the timestamp format somehow? For example, TimestampMigrator could produce a warning when it notices a timestamp that is neither a date, date and time or Unix epoch integer. Or maybe even support a configuration option to enforce a particular format

You can reproduce this behavior with the following files:

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

gem "sequel"
gem "rake"
gem "sqlite3"

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

require "bundler/setup"
Bundler.require

namespace :db do
  desc "Run migrations"
  task :migrate, [:version] do |t, args|
    Sequel.extension :migration

    Sequel.connect("sqlite://dev.db") do |db|
      Sequel::Migrator.run(db, "db/migrate")
    end
  end
end

# db/migrate/200011223344559_invalid_timestamp.rb
#                          ^
Sequel.migration do
  change { puts "Migration with extra digit in timestamp" }
end

# db/migrate/20251122334455_valid_timestamp.rb
Sequel.migration do
  change { puts "Migration with valid timestamp" }
end

rake db:migrate
# =>
#   Migration with valid timestamp
#   Migration with extra digit in timestamp

[jeremyevans]

By design, Sequel does not enforce a particular timestamp pattern. There is no possibility of doing so by default without breaking existing applications.

I would be open to a new feature so that users could specify the expected version format via an option, and Sequel would raise an exception if there was a migration file present that did not use that format.