Closed pkarjala closed 3 months ago
Yes, you are right. This need to be fixed.
Thank you!
Small suggested tweak to this, instead of hard-coding it as [7.0]
, you could use the following on generation:
"[" + ActiveRecord::Migration::current_version.to_s + "]"
Documentation: https://api.rubyonrails.org/classes/ActiveRecord/Migration.html#method-c-current_version
This will always return the current ActiveRecord version as a two digit float, and will be both forwards and backwards compatible across various Rails versions.
There are also more complex methods for invoking the generator directly instead of manually copying a file; instead you pass in arguments for the data you want generated. See https://api.rubyonrails.org/classes/Rails/Generators.html#method-c-invoke for documentation, and https://github.com/devise-two-factor/devise-two-factor/blob/bb9f435d1d1a17a7f52f62c547ae53bcdceabb96/lib/generators/devise_two_factor/devise_two_factor_generator.rb#L17 for an example.
This should always properly generate the version number since it creates the entire generation file from scratch each time. The downside is you have less control over exactly what is generated; if you want specific migrations, the method currently used is probably better.
Hope that helps!
I was thinking about it but then it could be that a change in Rails will make the file wrong, no? Maybe it's not as likely tho and we could have this dynamically done. Contributions are welcome.
This is actually intentional; Rails wants to know what version of ActiveRecord a migration was generated with so that it will correctly apply certain considerations since ActiveRecord has changed and will continue to change over time. So an older migration that happened on Rails 5.1 can still run on Rails 7.1 without compatibility issues as long as it is properly labeled. Moving forward, migrations made on 7.x will run fine under 8.x and so forth since ActiveRecord knows what version the migration was created with.
See the comments on https://github.com/rails/rails/blob/53f703b3e84aebf7799f24092cf3c2976f94b4be/activerecord/lib/active_record/migration/compatibility.rb#L1 for more information.
Yes, hence my comment and why I hardcoded it. The migration file already exists and is written against Rails 7 (well technically older version but I put 7). So Rails will know how to migrate it.
Apologies--for some reason I had in my head that devise-otp was dynamically generating this each time the migration was run, not copying an existing pre-generated migration.
Yes, the hard-coded version is fine! Sorry for the unnecessary back-and-forth.
When initially setting up this gem on a Rails 7.1 project and generating the migration for the user model
rails g devise_otp user
it generates something like:
Attempting to run this migration results in the following errors:
The version number of Active Record must be included with the migration generated as of Rails 5.x (as far as I could find). It would be good to build this into the generators for the migrations that devise-otp creates, or add documentation to manually add the version number after running the generator.