Skip to content

Conversation

@rueckstiess
Copy link
Contributor

@rueckstiess rueckstiess commented Mar 29, 2017

They haven't been useful since 1.1.5 and are taking time to load on every upgrade.

If someone upgrades from 1.1.5 to 1.8, they will

  • either lose their connections and privacy settings
  • or have to install any version in between first to migrate, and then start 1.8.

I'm ok with this, given we even have a work-around.

Copy link
Contributor

@pzrq pzrq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Compass 1.8.0-dev still starts as expected. Of 3 test runs on local at least one completely passed for me.

Copy link

@satyasinha satyasinha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@satyasinha satyasinha merged commit 28be47d into master Mar 29, 2017
@satyasinha satyasinha deleted the kill-main-migrations branch March 29, 2017 06:53
@leafybot
Copy link

leafybot commented Mar 29, 2017 via email

@pzrq
Copy link
Contributor

pzrq commented Mar 31, 2017

For posterity, one reason it was decided to kill these main process migrations was that they would combine with the functional tests when you ran npm test -- --functional on a macOS machine. Specifically if you had also started a Compass v1.1.5 or earlier on the same machine, they would hang for 60 seconds generating the screenshot below (which affected my macOS box for nearly four months via #664). This is something which also never happens on Travis.

macos local needs fixing

From my previous experience with Django unit testing and the community's response, I continue to strongly suggest the Compass Team follows the pattern that migrations should (as a general rule) be run all the time when running tests, so we would expect to run them on Travis and on localhost when running npm test. Plus they only took a second or two, unlike Django's SQL+ORM ones which can take minutes or even hours.

This also gave us this trigger to allow such a cleanup, which would most likely not otherwise have occurred until hypothetically in the very very long arc of time something like a new node version breaks AmpersandModel which would break these migrations and thus error, most likely in production only.

TL;DR: Migrations don't need to be forever.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants