Редактирование существующих Rails Migrations - это хорошая идея?

При запуске нового проекта в моделях есть много изменений, которые, как мне кажется, легко редактировать существующую миграцию & amp; бежатьdb:clean или жеdb:reset чем создать новую миграцию. Я делаю это, когда приложение не запущено, а это значит, что я могу перезагрузить / очистить базу данных без забот & amp; Я работаю соло или являюсь частью небольшой команды.

Но сегодня я наткнулся на следующий совет вРуководство по рельсам говорят, что это не очень хорошая идея препятствует редактированию существующих миграций:

Editing existing migrations is not a good idea: you will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines. Instead, you should write a new migration that performs the changes you require. Editing a freshly generated migration that has not yet been committed to source control (or, more generally, which has not been propagated beyond your development machine) is relatively harmless.

Я хочу знать:

what potential pitfalls I can run into ? Does those pitfalls apply in my case(development stage,working solo)?

Ответы на вопрос(3)

самое важное - понять, для чего он нужен, как его использовать и зачем его использовать таким образом.

Live Site: In a live site you can't simply use rake:db reset because clearly you need all that data In collaboration: You need to maintain migrations in consistency with other developers. What if they have entered data into their database (for whatever purpose) and simply mixed in your code. You've now completely foobared their efforts and they will be compelled to reset their entire database Rake db:rollback : Once you've modified the code you'll have to reset, now you can't run rollback. It's a bad habit: In the majority of cases the polite manner in which to do this is to create a new migration. It is better to be in the habit and of the mindset to be able to quickly and efficiently create new migrations.

Я на самом деле не говорю вам не делать этого. Это только основные моменты, почему бы не сделать то, что я вижу. В большинстве случаев, если вы один, или особенно если вы только формируете свой проект (и, возможно, не сразу понимаете, как вы хотите, чтобы база данных выглядела / работала, играя с ними напрямую, могут быть наиболее эффективными. Важно понять, почему и поэтому перед тем, как вы начнете шутить против лучшей практики.

рекомендуется использовать миграции для изменения базы данных. Это может оставить след модификаций, но вы можете увидеть эволюцию структуры вашей базы данных. В конечном итоге вы будете быстрее решать проблемы БД с миграциями.

Если это только в вашей локальной среде, просто создайте новую миграцию, исправляя то, что вам нужно. Вы можете удалить таблицы \ столбцы и делать то, что вам нужно.

Так как вы очищаете базу данных и сбрасываете ее, тогда все будут делать то же самое, или у них будут проблемы, если они попытаются мигрировать.

ВАШ ОТВЕТ НА ВОПРОС