IOS Перемещение обновлений приложений. Сохранение пользовательских данных в случае необходимости обновления БД

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

Я выпустил первую версию приложения. Я сделал несколько изменений в SQLite db с тех пор, в следующей версии мне нужно будет обновить структуру БД, но сохранить пользовательские данные.

Какой лучший подход для этого? В настоящее время я думаю, что при обновлении приложения я никогда не буду заменять файл базы данных пользователя (папка с документами, а не в пакете), а скорее изменять его структуру, используя SQL-запросы.

Это будет связано с отслеживанием изменений, внесенных в базу данных с момента предыдущего выпуска. Script все эти изменения в SQL-запросах и запустить их, чтобы довести БД до последней версии. Мне также необходимо сохранить поле в базе данных для отслеживания номера версии (для простоты).

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

Выполняя это, я покажу "Обновление приложения" или что-то пользователю.

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

Должен ли я взять это на себя, чтобы просто удалить файл DB пользователя и заменить его новой версией из пакета приложений. ИЛИ, должен ли я просто протестировать, протестировать, протестировать, пока все не станет твердым на моей стороне, и если на стороне пользователя возникнет ошибка, это что-то еще, и в этом случае я ничего не могу с этим сделать, только отбрось данные.

Любые идеи по этому поводу будут очень признательны.:)

Спасибо!

Ответ 1

Прежде всего, подход, который вы рассматриваете, является правильным. Это называется миграцией базы данных. Всякий раз, когда вы изменяете базу данных на своем конце, вы должны собрать соответствующие методы ALTER TABLE... и т.д. В перенос script.

Затем следующая версия вашего приложения должна запускать этот код один раз (как описано) для переноса всех пользовательских данных.

Что касается обработки ошибок, это сложно. Я бы очень устал отбрасывать данные пользователя. Лучше было бы отображать сообщение об ошибке и, возможно, позволить пользователю связаться с вами с сообщением об ошибке. Затем вы можете выпустить обновление для своего приложения, которое, надеюсь, сможет выполнить миграцию без проблем. Но в идеале вы достаточно хорошо проверяете процесс, чтобы не возникало таких проблем. Конечно, все зависит от сложности процесса миграции.