It seems that I didn't explain the use case correctly. We support a backup and restore of our DB (postgres) via native dump tool.
V - We do copy migration files from engine to main application. engine/db/migration/*201700000000*_add_expiration V - Also we rename (re-date) those migration files before migrator, main/db/migration/*201800000000*_add_expiration now, when user run backup & restore in new DB - timestamp meta table will hold filename: *201800000000*_add_expiration When application code do the same flow V - copy migration files from engine to main application. engine/db/migration/*201700000000*_add_expiration V - Also we rename (re-date) those migration files before migrator, main/db/migration/*201900000000*_add_expiration Running rake db:migrate we get an error, since in the schema_migration meta table expecting exactly filename: *201800000000*_add_expiration and we have *201900000000*_add_expiration on our filesystem. The re-date thing only run on physical file system files and not changing the meta table record to be correlated. If Sequel will compared only "add_expiration" without version & scope when running db:migrate, it will be OK since the file and it's content are the same, just the version&scope changed. On Tuesday, September 24, 2019 at 5:48:21 PM UTC+3, Jeremy Evans wrote: > > On Tuesday, September 24, 2019 at 2:22:52 AM UTC-7, D-lev wrote: >> >> Hi, >> We have develop a task to migrate files from db/migration at engine level >> to the wrapper. >> something activerecord already have: >> >> https://github.com/rails/rails/blob/16f2cd88e3ee92de341ba30b102e9206be3c68a7/activerecord/lib/active_record/migration.rb#L886 >> >> One important instruction there is to update version (timestamp) while >> moving those files to the main wrapper. >> i.e: 20180508164825_add_expiration.rb will become >> *20190924*164825_add_expiration >> after task done. >> Now, TimeStampMigrator is looking in FS for 20180508164825_add_expiration >> and not for *20190924*164825_add_expiration since Sequel relies on full >> name including version and not only search for "add_expiration" >> in schema_migrations table. >> >> Possible workaround is [ >> https://stackoverflow.com/questions/39853525/how-to-ignore-a-missing-migration-with-sequel-s] >> to >> override db:migrate tasks and to add >> >> Sequel::Migrator.run(db, "db/migrations", allow_missing_migration_files: true >> >> >> What is your opinion? >> >> > I guess I don't understand the problem. It sounds like you want to copy > the migration file from an engine to the main application. As long as you > copy and rename the migration file before running the migrator, you should > be fine. If you run the migrator before renaming the file, you can update > the table with the stored migration filenames to reflect the new name. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/b44dfec7-eab8-40d6-8f46-9ffab2cbc011%40googlegroups.com.
