This project is archived and is in readonly mode.

#1304 ✓invalid
Jordi Bunster

[PATCH] Readable schema.rb timestamp

Reported by Jordi Bunster | October 30th, 2008 @ 08:07 PM | in 2.x

This patch makes schema.rb a bit easier to merge in case of conflict, by going from this:


ActiveRecord::Schema.define(:version => 20380119000001) { ... }

to this:


ActiveRecord::Schema.define(:version => '2038-01-19 00:00:01') { ... }

It only does it to UTC timestamp versions. It doesn't meddle with the old style sequential versions.

Comments and changes to this ticket

  • Jordi Bunster

    Jordi Bunster October 30th, 2008 @ 08:48 PM

    Revised to add a comment instead.

  • Jordi Bunster

    Jordi Bunster October 30th, 2008 @ 09:10 PM

    Revised to remove old, misleading commit message.

  • DHH

    DHH October 31st, 2008 @ 05:47 PM

    I know I suggested this approach, but I'm having second thoughts on how it's going to help anything. If you're merging the schema.rb, won't you be relating to the migration timestamps, which are in the compressed format anyway?

    Could you explain a merge that would be easier to do after this?

  • Jordi Bunster

    Jordi Bunster October 31st, 2008 @ 06:14 PM

    If you pull from a branch, and it turns out there're three conflicts in schema.rb, how do you solve them?

    What I do for all but the first conflict, is to look at the conflicts, and understand the other author's intentions.

    But to solve that first conflict (define(:version => 'foo')), requires even less: you just pick the newest date. The problem is that many times they're a pain to tell apart. Or maybe it's just me:

    20081016160846 vs. 20081015035216 (which is newer?)

    I'm actually starting to disagree with the idea of schema.rb. Much like you, I'd like to not have the maintenance burden to keep migrations working forever, but... new migrations files (specially now with UTC timestamps) just merge cleanly across branches. It's hard to beat that.

    So maybe for me the answer is to keep schema.rb out of version control, and from time to time, use the schema dumper to create a "rolled up" migration.

    P.S: another alternative to this is to use Ruby's native support for underscores inside integer literals ... both on the filenames for migrations and on the literal passed to #define.

  • DHH

    DHH October 31st, 2008 @ 06:30 PM

    But why do you have conflicts in the first place? If everyone has run the same migrations, why would there be conflicts?

  • Jordi Bunster

    Jordi Bunster October 31st, 2008 @ 06:40 PM

    Oh. Because of the same reasons that numbered (non-UTC) migrations were a pain: different developers work on different migration files in their respective branches.

    Bob forks master, and creates two migrations. Jane forks master, and creates one migration. Jane is done working, and pushes to master. Bob is done working, but before pushing to master, pulls from master. Boom. Jane's migration files merge cleanly, but her copy of schema.rb conflicts with Bob's.

    On Oct 31, 2008, at 2:30 PM, Lighthouse wrote:

  • Jordi Bunster

    Jordi Bunster October 31st, 2008 @ 06:43 PM

    Damn, on the email, that reply had newlines:

    • Bob forks master, and creates two migrations.
    • Jane forks master, and creates one migration.
    • Jane is done working, and pushes to master.
    • Bob is done working, but before pushing to master, pulls from master.
    • Boom. Jane's migration files merge cleanly, but her copy of schema.rb conflicts with Bob's.

    There. Formatted. :)

  • Ryan Bates

    Ryan Bates October 31st, 2008 @ 09:39 PM

    I run into this conflict problem quite frequently too. It's really the only painful part left when working with migrations and branches.

    However, I don't think making the "version" date cleaner is a good solution. It makes more sense that the version matches the migration number exactly. This also won't solve the core issue - there will still be conflicts over this date.

    What purpose does this version number serve? With the new way of migrations it doesn't make as much sense because it doesn't tell the entire picture. You can still have missing migrations before this version which may or may not be represented in the schema.

    Technically it should mention every version which has been migrated (like the schema_migrations table) but that isn't very practical here. Can we just remove it entirely?

  • Jordi Bunster

    Jordi Bunster October 31st, 2008 @ 11:03 PM

    That's a good point.

    We only pass one version, and when rake db:schema:load runs, it assumes we've migrated all the way up to that. If it turns out that somehow schema.rb is missing one of the ones in the middle, then you'd have to find out which one, and run rake db:migrate:up VERSION="missing_foo" to force it.

    If you get rid of the version, we'd have to assume that all have run, which means the possibility of the scenario described above increases a bit.

    I guess the problem is deeper than I thought.

  • DHH

    DHH November 23rd, 2008 @ 01:15 PM

    • State changed from “new” to “invalid”
  • bingbing

    bingbing March 26th, 2011 @ 01:14 AM

  • wengwo

    wengwo May 22nd, 2011 @ 07:40 AM

    ff

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Tags

Referenced by

Pages