Migration version conflicts

[dyu]

Hi,

We've noticed in our merges that we have SQL migration version conflicts. For example, we both added version V642. For now we are simply changing migration versions to solve this issue, which is far from ideal - if the migrations have been run in post-dev environments, we'd have a lot of problems.

While we talked about re-arranging these migrations to be in their own modules in the long run, in the short term we can think of several ways to alleviate this -

1. Always notify the other teams when a new migration is added so they can merge in asap

2. Avoid adding migrations on feature branches

3. Add minor version numbers for migrations (e.g. Moz will always append _1 after version number for our migrations?)

4. Add independent migrations to another module? (db? new module? probably not a good idea...)

Any thoughts and suggestions?

[Jie Xiong]

Ruby on Rails used sequence migration version numbers at its early days. Then they had the same problem and decided to use timestamp in migration names (e.g. 2015111016130387_add_nick_name_column_to_people_table). Is it a possible solution to our problem here?

--

Jeff Xiong
ThoughtWorks
+86 186 826 53819

[dyu]

This is a great great point. I remember it being brought up in one of the tech huddles, but I can't recall why we did not do this - Rich / Josh / Elias, do you remember? We will still be in touch in case there are migrations with conflicted actions (e.g. one renamed a column and the other changed the column type), but I think using timestamp will solve most of the problems. 

[Josh Zamor]

It's true, we've known about this for a LONG time.  At first I didn't make this switch as I recall Flyway needed to be upgraded, which meant it wanted Gradle to be updated, and the rabbit hole across projects went from there.  At this point Gradle is much newer and I'm not sure if Flyway has been bumped up a version or not yet.  The other reason I hadn't pursued this is I didn't want to surprise the new VIMS project team as we were working in their space.  Now I think we can certainly move the teams this way so long as we can notify everyone that the change is coming and what to do instead. 

Which brings me to my question:  RoR has a nice migration generating script which at the very least is useful for generating the filename with the timestamp, while formatting the timestamp is something a dev can easily do, does anyone know of a quick and near-universal tool which we could use across projects like RoR has?  Minus the ActiveRecord ORM type stuff of course.

Best,
Josh

(I'll grab converting Flyway if no one wants it - though I'm getting on a plane and may not get to it for awhile)

[Danni Yu]

Yeah Gradle can definitely be upgraded to very recent versions, but Flyway we're still on 1.7. I vaguely remember that our team tried to upgrade Flyway to the latest when we first started the project but encountered some issues at that time...

About generating migration file names - we can write a script / gradle task to generate file names by using timestamp as version number and argument as the migration name.

[Josh Zamor]

I just got a chance to check myself on this and realized I was conflating two past issues:  version scheme and out of order migrations.  The latter needed a flyway upgrade, the former is possible with 1.7 - though it'd be good to agree on a format and for someone to graciously write up the script.

With that in mind thinking about the format only, I could propose two formats:

• Epoch (> date +s%)
  
• YYYYMMDDTHHMMSSZ

Epoch is nice since it's resolution down to the second and in UTC.  The latter is more human readable, is ISO8601, though maybe a little harder to generate.  I think I myself prefer the latter though unless I write it I realize my opinion is just that.  Thoughts?

[Rich Magnuson]

I created ticket OLMIS-50 for this one.  I didn't add much detail as much of the discussion is already  here.   Any further thoughts on the date format?  

[Chongsun Ahn]

Hey all,

I would prefer the latter format for migrations. More readable, and that’s what Ruby on Rails uses.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

-- 
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2a333cb0-d436-4c7a-818c-58d8a3925489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.