Ошибка абсолютно ничего дельного не говорит

Но если надо, могу и ее отправить

Если юзеры не меняют данные, я вообще не вижу проблем. Бэкапа тоже не было перед накатом миграций? Если был, какие проблемы?

Нафига бекап раскатывать??? Ты хоть знаешь сколько времени будет раскатываться пара терабайт данных?

А без пары терабайт вообще жизни нет?

Я к чему клоню: мне тут постоянно говорят - кто про 500 терабайт, кто про 2. Это так всегда или все же на редких проектах?

Если обычно бэкап делается и при необходимости восстанавливается быстро, то я бы хотел говорить о том, что бывает обычно, а не на специальных проектах автоматизации глобальной энергосистемы планеты.

Почему-то думаю, что глобальная энергосистема планеты не хранит много данных))

Ну от проектов зависит. Если мы говорим о каких-нить erp или, не дай бог, о bpm... там овердофига данных.

Бекапы делаются постоянно. Но бизнес не готов ждать дни, пока ты накатишь дамп. Дампы только для серьезных инцидентов.

А если ты при выкатки релиза получил ошибку, то откат миграции займет минуты

У меня начинает появляться какая-то чуйка. Спасибо.
Но пока плохо вкручиваю.

Еще бы пример ситуации. Можно такой пример типа:
1. Было вот это в БД.
2. У нас задача изменить БД и получить вот это.
3. Сделали миграции вот такие.
4. Мигрировали.
5. В проде все плохо.
6. Откат миграции.
7. Правим код неделю.
8. Подготовили новые миграции вот такие.
9. Накатили.

Ну вполне нормальный кейз. 5 пункт это, например, прогон тестов, которые показали критическую ошибку

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

Вот что может такое быть? Ну, что? Надо простейшее. Ну, допустим,
1. Были  автор и книга. Так получилось, что они существовали отдельно.
2. Нам надо сделать связь многие ко многим. Чтобы у книг появились авторы.
3. Сделали миграции, но заложили каскадное удаление. Если удалить автора, то удалятся книги.
4. Мигрировали.
5. Елки зеленые. Надо ON DELETE RESTRICT.
6. Откатили миграцию.
7. Правили неделю.
8. Подготовили ON DELETE RESTRICT.
9. Кайф.

Это очень плохой пример. Потому что он ничего не отражает. Ну, если бы были миграции подготовлены автоматически, то я бы поле просто вручную грохнул последнюю миграцию в джанге. И поправил код в модели. И создал новую миграцию. И заняло бы это две минуты. А не неделю.

Так что плохой пример. А можно как-то придумать хороший?

Реорганизация базы с изменением нескольких таблиц, где удаляется и добавляется какое-нибудь несимметричное число полей. Пропустили баг. Откатывать эту миграцию руками, тем более на проде - недопустимо в практически любой серьёзной компании. Должны быть готовы механизмы автоматического фоллбэка. То есть откат миграций.

Допустим, удаляли два поля, добавляли три поля.
Как писать миграцию?
Если мы просто удалим поля, в бд, то откат миграции их вернет?

Так тут написано:

While the idea of undo migrations is nice, unfortunately it sometimes breaks down in practice. As soon as you have destructive changes (drop, delete, truncate, …), you start getting into trouble. And even if you don’t, you end up creating home-made alternatives for restoring backups, which need to be properly tested as well.

Т.е. это ни от чего не спасает, по сути.

>ничего не спасает
>SOMETIMES breaks

всем добрый вечер, кто хорошо знаком с java netty и архитектурой многопользовательских игр, нормально ли так реализовать поиск игры  ?

Разумеется, если в миграции ты делаешь дроп табле, то откатить это будет сложно. Тут зависит от миграции

Ну, я вообще ничего не понимаю.

Давайте по порядку.

1. Изначально вопрос стоял, почему в мире спринга нет автоматического средства создания миграций.
2. Меня попросили примеры, я привел ROR и Django. Ладно, ROR я привел неудачно просто потому что я его толком не знаю. Скажем, с ROR я не справился (хотя, я думаю, там именно миграции вручную все же не пишут, просто я не смог это показать).  Но в Django тончо есть автоматическое создание миграций.
3. Мне говорят - вот нам нужно откатить миграции.
4. Я начинаю читать - откат не панацея. Небезопасно.
5. Пишите приложения так, чтобы была обратная совместимость. This way a failed migration is not a disaster. The old version of the application is still compatible with the DB, so you can simply roll back the application code, investigate, and take corrective measures.


Вопрос: а как оно связано с отсутствием средства конвертации POJO в миграцию? Ну, если откат не панацея, а панацея только правильная архитектура приложения - такая, чтобы откатиться можно было в принципе, при чем тут автоматическое создание миграций-то?

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

Так что вопрос все же открыт и по факту автоматическое создание миграций удобно. А средства для этого нет.

Я думаю так:
на джаве чаще пишут большие проекты чем на питоне => надежность играет бОльшую роль => поэтому люди предпочитаю явно писать миграции, а не неявно создавать их из моделек, где не всегда есть четкое понимание что будет в базе.

Но возможно на средних и малых проектах - такая штука будет акутальна. Вряд ли ее сложнее создать под JPA чем под питон.

Ок. Тогда возникает два вопроса:
1. При наличии средства автоматической подготовки миграций кто мешает явно писать миграции? Если кто-то предпочитает, ну, пусть пишет.
2. Когда я выбирал, что изучать, был под впечатлением, что на джаве все есть. Т.е. если человечество что-то когда-то делало, то оно точно делало это на джаве. Т.е. на джаве есть все. Не надо думать о том, что чего-то нет из вспомогательного. Думай только о своей бизнес-логике. Остальное уже сделано за тебя.
Начинаю пробовать свои силы: а где, собственно? Это что же человечество автоматически не готовило миграции ни разу?