-
Notifications
You must be signed in to change notification settings - Fork 914
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore the users.nearby column #2432
Conversation
This is the first step of removing the column, see openstreetmap#2417. It needs to be deployed before a migration to remove it, since the columns are cached in ActiveRecord and things break if objects exist in memory that expect the column to be there.
Well if you really want to pander to |
I'm surprised by your attitude here @tomhughes, it's not very helpful. Without doing this, if we just ran the migration to drop the column, then anyone in the middle of doing anything with a User object (i.e. already read from the database and then writing to the database) can receive an error. Creating a user, updating their preferences, etc. So you run the migration, and people see errors. I want to avoid that. I don't consider this to be "pandering to ... extremist nonsense" and it's a) a pretty trivial solution and b) not something that I'm burdening you with. If I haven't yet convinced you that |
Yes it might cause a breakage for the couple of minutes between me running the migration and then doing a coordinated deployment on the web servers. I just think that this, like many of |
Creates a lot of work? The two options are: a) run a migration, which breaks things in production, or Seems like an easy choice to me. |
I was assuming you would leave it in. Yes I know that doesn't actually help but it's easy to think it does unless you think it through carefully ;-) |
This is the first step of removing the column, see #2417. It needs to be deployed before a migration to remove it, since the columns are cached in ActiveRecord and things break if objects exist in memory
that expect the database column to be there.
Thanks to
strong_migrations
for pointing this out when I tried creating the migration first!