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

Question

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

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

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

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

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

При этом я покажу пользователю «Обновление приложения» или что-то еще.

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

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

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

Спасибо!

Answer 1

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

Тогда следующий выпуск вашего приложения должен выполнить этот код один раз (как вы описали), чтобы перенести все данные пользователя.

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