Rails: Is the version number in 'schema.rb' used for something?

Question

Now that Rails has timestamped migrations , the only version number at the top of /db/schema.rb seems pointless. Sometimes the version number is incorrect when working with multiple developers or multiple branches.

Can Rails use this option :version ?

And is there any harm in the fact that it is incorrect (as in: it does not reflect the time stamp of the last applied fixation)?

Example:

 ActiveRecord::Schema.define(:version => 20100417022947) do # schema definition ... end 

Answer 1

Actually, the version is much more important than this. The code you provided is actually just a small part of what pred_migrated_upto_version does. The real effect of the version for migration is that all previous migrations (as indicated in the db / migrate directory) are considered to be running. (So ​​yes, it does what the function name is.)

This has some interesting consequences, especially when several people make new migrations at the same time.

If you are using the version of schema.rb that the Rails team recommends, you're fine. You are 100% guaranteed to have a conflict (version of the scheme), and the user committing / merging should solve it by combining his changes and setting the version: to the highest of the two. I hope they work correctly.

Some projects prefer to avoid this constant conflict problem by leaving schema.rb out of version control. They can rely solely on migration, or keep a separate version of a versioned schema, which they sometimes update.

The problem occurs if someone creates a time-stamped migration to your version of schema.rb :. If you do db: migrate, you apply their migration, your schema.rb will be updated (but keep the same, higher version) and everything will be fine. But if you should happen with db: schema: load (or db: reset) instead, you will not only miss their migration, but pred_migrated_upto_version will note that their migration has been applied.

The best solution at this stage is likely to require users to re-mark their migrations before they merge.

Ideally, I would prefer that the schema.rb scheme actually contains a list of applicable migration numbers, rather than the "take over" version :. But I doubt that this will happen - the Rails team seems to think that the problem is adequately resolved by checking in the schema.rb file.

Answer 2

I decided to research myself. It turns out that because of the time migrations marked by Rails, the only thing Rails does with this number is , suppose that the migration with this particular timestamp has already been applied and thus create the appropriate entry in the schema_migration table if it does not exist.

from: /lib/active_record/connection_adapters/abstract/schema_statements.rb

 def assume_migrated_upto_version(version, migrations_path = ActiveRecord::Migrator.migrations_path) # other code ... unless migrated.include?(version) execute "INSERT INTO #{sm_table} (version) VALUES ('#{version}')" end # ...