Change migrations to be timestamped instead of sequential numbers #5

Merged
merged 1 commit into from Dec 24, 2014

Conversation

Projects
None yet
10 participants
Contributor

ctide commented Sep 14, 2011

I was about to write this tool this morning, and saw yours and decided I'd just make the one modification to it that we needed to make it work for us.

Resolves #2 as well.

Owner

tj commented Sep 14, 2011

im still not a huge fan personally, though I understand the argument

Contributor

stephenmelrose commented Mar 15, 2012

+1 for the reasons stated in #2.

We work in a large code base and in the youth of a project it's feasible for two people to create migrations in different branches, and with this naming convention, it would cause issues.

Personally not a fan of timestamp, would prefer a "2012-03-15_15-47_" prefix format, but each to their own. Definitely better than an incremental prefix though.

+1

Even if I'm discussing a migration with another developer to ensure no logical overlap, I still don't want to have to wait until he pushes just to create a new migration (to prevent number clashing).

As ctide said, let's learn from the Rails community's mistake.

This is crucial for being able to work on features in parallel where the developers will generate migrations as part of their features.

Not having this, you end in situations like this example. Say John is working on feature A, and Dave is working on feature B. John has created migration 015 as part of their feature branch, and Dave has created migration 015. Whoever merges their feature into the master codebase first would need to tell the other person to adjust their migration number, which means that developer would have to alter their migration number, but also their .migrate file, or alternatively migrate down, then merge master into their feature branch, adjust their migration's number, then run migrations up.

Imagine if you have more than two developers who are working on feature branches in parallel and making migrations as part of their feature branches. You would have to perform this for each developer who didn't merge first. That would be a minimum of those 2 tasks for each developer, provided that all of the developers were aware of the migration number conflict at the same time. If another developer (named Gary) doesn't do that, and commits 016 whilst Dave is trying to alter his migration number from 015 to 016 because John committed 015 first, then it 2 * 2 tasks for Dave, and potentially the rest of the developers who were following Dave's actions as well.

In short, this is a pain in the butt. Timestamps would make life much easier.

Owner

tj commented Oct 16, 2013

this module could use some maintainers if anyone is interested, I haven't used it in quite a while

I'm happy to volunteer some time to maintaining this library.

Is there any plan to address this issue?

Contributor

ericsaboia commented Feb 20, 2014

I can also help maintaining.

@tj It looks like this lib gets quite a bit of traffic naturally, given its name. I wonder if you could take a minute to promote some maintainers to move this forward and make it a more generally useful tool. Thanks man!

@joaosa joaosa merged commit 36f7c98 into tj:master Dec 24, 2014

@michelob michelob referenced this pull request in emirotin/mongodb-migrations Jan 27, 2015

Closed

Consider using timestamps rather than incremental numbers... #6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment