Если вы когда-нибудь использовали greenDAO, вы, вероятно, использовали их DevOpenHelper класс. Как следует из названия, он помогает вам открыть базу данных, но также определяет, что происходит при изменении версии вашей схемы. Если вы прочитаете документацию по этому классу, вы увидите следующее: WARNING: Drops all table on Upgrade! Use only during development.
Поэтому, если вы когда-нибудь измените свою схему (например, добавите новую таблицу), она сначала отбросит все таблицы, стирая базу данных. Для разработки, где схема постоянно меняется, это может подойти. Но как только ваше приложение будет выпущено, ваши пользователи, вероятно, не будут довольны, если все их данные будут удалены при обновлении.
Вот тут-то и возникает миграция базы данных, и почему вам не следует использовать DevOpenHelper в производственной среде. Вместо того, чтобы удалять все свои данные, вы можете указать greenDAO, как обрабатывать изменения версии схемы. Таким образом, ваши данные не будут потеряны, а обновления приложений будут плавными.
Настройка миграций
Чтобы продемонстрировать это, я взял пример приложения из GitHub greenDAO и изменил его, включив в него миграции. Вы можете найти мой пример проекта здесь. Ниже представлена окончательная версия класса, используемого для выполнения миграций.
Если вы хотите попробовать, вы можете клонировать мой пример проекта и проверить фиксацию 689fa205d87e5c74f27e25588eb1b2a5f41588be. Это приведет вас к первой версии схемы. На данный момент есть только Note таблица. Если вы попробуете запустить приложение, вы сможете добавить заметки в базу данных.
Теперь, если вы проверите следующую фиксацию 23fd3802fd105873584023c807b60120b93da142, вы перейдете ко второй версии схемы. В этой версии я добавил User таблицу. Если бы вы использовали класс DevOpenHelper, запуск приложения здесь приведет к удалению ранее сделанных вами заметок. Поскольку мы выполняем миграцию, этого не произойдет. Если вы запустите приложение, вы можете попробовать добавить пользователя, и вы увидите, что ваши заметки все еще там.
Наконец, если вы ознакомитесь с третьей версией схемы 5c1367164620858c814cf87860771c06c8140f77 и установите приложение, оно выполнит еще одну миграцию. В этой версии я добавил age к User. Если вы запустите приложение, снова никакие данные не будут потеряны, и теперь вы можете установить age для User.
В этом примере мы также могли перейти прямо с версии схемы 1 на версию 3, и миграции по-прежнему работали бы. Вместо одной миграции было бы выполнено две. Неважно, с какой версии обновляется пользователь, миграции все равно будут работать.
Последние мысли
Вам нужны миграции только тогда, когда вы выпускаете новую версию приложения и внесли изменения в базу данных. Если вы находитесь в разработке и постоянно вносите изменения в базу данных, вам не нужно постоянно обновлять версию схемы. Хотя вы должны знать, что во время разработки, если вы добавите новую таблицу, например, и обновите приложение на устройстве, на котором оно уже было установлено, оно не обновит базу данных. Поскольку версия схемы не изменилась, это приведет к сбою приложения, если вы попытаетесь запросить базу данных для этой таблицы (поскольку она еще не существует).
Иногда во время разработки лучше просто продолжать использовать DevOpenHelper и обновлять версию схемы. Просто не забудьте вернуть его для выпуска. В качестве альтернативы, если вы обновите схему базы данных, вы можете очистить данные для своего приложения. Таким образом, он заставит его воссоздать базу данных с измененной схемой.
Если вам понравилось читать, пожалуйста, нажмите "Это маленькое сердечко". Если вы хотите узнать больше, подписывайтесь на меня на Medium. Спасибо!
Первоначально опубликовано на сайте piercezaifman.com 4 февраля 2017 г.
