Kapag bumubuo ka ng isang aplikasyon, normal lang na mag-evolve ang mga pangangailangan ng proyekto. Habang nagdaragdag ka ng mga feature, mapagtatanto mo na Mga klase ng entidad ng silid at ang mga kaukulang talahanayan nito ay kailangang baguhin upang umangkop sa mga bagong kinakailangan. Ang malaking hamon dito ay ang pagtiyak na hindi mawawala ang anumang data ng gumagamit kapag na-update ang app at nagbago ang iskema ng database.
Upang matugunan ito, nag-aalok ang Room ng iba't ibang opsyon, mula sa pinakasimple hanggang sa mas detalyadong mga implementasyon. Depende kung ang pagbabago ay isang simpleng pagdaragdag ng column o isang kumpletong restructuring, maaari kang pumili mula sa awtomatiko o manu-manong mga paglipatpalaging tinitiyak na ang transisyon ay maayos at hindi magiging sanhi ng biglaang pagsasara ng aplikasyon.
Ang mabilisang landas: Mga Awtomatikong Paglipat
Simula sa bersyon 2.4.0-alpha01, pinapadali ng Room ang ating buhay gamit ang mga awtomatikong paglipat. Sa esensya, sinusuri ng framework ang mga pagkakaiba sa pagitan ng luma at bagong mga bersyon at binubuo ang plano ng paglipat para sa atin. Para i-activate ito, idagdag lamang ang anotasyon. @AutoMigration sa loob ng property na autoMigrations sa @Database decorator.
Tandaan, mayroong isang mahalagang detalye: para gumana ito, Dapat itakda sa true ang exportSchemaKung hindi mo pa nae-export ang schema o na-compile ang database gamit ang bagong version number, hindi malalaman ng Room kung ano ang nagbago at mabibigo nang husto ang migration.
Mga kumplikadong kaso sa awtomatikong mode
Minsan, medyo nagkukulang ang Room at nakakakita ng mga hindi malinaw na pagbabago, tulad ng kapag nagpasya kang magbura ng talahanayan o palitan ang pangalan ng kolum. Sa mga kasong ito, magpapakita ang compiler ng error at hihilingin sa iyo na ipatupad ang isang AutoMigrationSpecSa static class na ito mo binibigyan ang Room ng karagdagang impormasyong kailangan nito para maiwasan ang pagkaligaw.
Sa loob ng Spec na ito, maaari kang gumamit ng mga anotasyon tulad ng @Palitan ang Pangalan ng Table upang gabayan ang sistema. Bukod pa rito, kung kailangan mong magpatakbo ng karagdagang code kapag nakumpleto na ang awtomatikong paglipat, mayroon kang sumusunod na paraan na magagamit. onPostMigrate()na mainam para sa paggawa ng mga pangwakas na pagsasaayos ng datos.
Ganap na Kontrol: Mga Manu-manong Paglipat
May mga sitwasyon kung saan hindi sapat ang automation, tulad ng kapag kailangan mong hatiin ang data mula sa isang table sa dalawang magkahiwalay na entity. Dito pumapasok ang manual migration, sa pamamagitan ng paglikha ng isang class na magmamana mula sa Paglipat at kung saan mo i-o-override ang migrate() method.
Sa pamamaraang ito, mayroon kang isang SupportSQLiteDatabase object na nagbibigay-daan sa iyong direktang isagawa ang mga SQL statement. Halimbawa, para magdagdag ng column, gagamit ka ng Baguhin ang talahanayanMahalaga na kapag nirerehistro ang mga rutang ito sa database builder, gamitin mo ang pamamaraan addMigrations().
Isang ginintuang tip: iwasan ang paggamit ng mga Kotlin constant sa loob ng iyong mga SQL migration query; sumulat kumpletuhin ang mga query sa SQLPinipigilan nito ang mga mapaminsalang error kung sa hinaharap ay babaguhin mo ang halaga ng isang constant ngunit kailangan pa rin ng lumang migration ang orihinal na halaga.
Mga advanced na estratehiya at pamamahala ng error
Kung nasa sitwasyon ka na hindi mo matukoy ang landas ng paglipat at wala kang pakialam kung mabura ang data (dahil maaaring isa lamang itong cache), maaari mong gamitin ang fallbackToDestructiveMigration()Dahil dito, burahin ng Room ang lahat at muling likhain ang mga talahanayan mula sa simula, na pumipigil sa app na mag-crash dahil sa isang IllegalStateException.
Para sa mas mahusay na kontrol, may mga alternatibo tulad ng fallbackToDestructiveMigrationFrom()na nagtatanggal lamang ng data kung ang user ay nagmumula sa mga partikular na bersyon, o fallbackToDestructiveMigrationOnDowngrade()Kapaki-pakinabang ito kapag may nag-install ng mas lumang bersyon ng app kaysa sa bago.
Mga naka-package na database
Minsan gusto natin na may kasamang pre-installed na data ang app. Pinapayagan ka ng Room na gawin ito sa pamamagitan ng lumikhaMulaSaAsset() o lumikhaMulaSaFile()Ang nakakainteres ay kung paano ito nakikipag-ugnayan sa mga mapanirang migrasyon: kung mayroon kang naka-package na file na tumutugma sa target na bersyon, gagamitin ito ng Room upang punan ang database pagkatapos magsagawa ng mapanirang paglilinis.
Ang sining ng pagpapalit ng pangalan at paghawak NOT NULL
Ang pagpapalit ng pangalan ng mga column sa SQLite ay maaaring maging sakit ng ulo, lalo na sa mga bersyon bago ang API 29. Ang pangunahing trick dito ay ang pattern lumikha-kopyahin-burahinGagawa ka ng bagong talahanayan na may tamang pangalan, ipapasa ang data gamit ang INSERT INTO … SELECT, at panghuli, buburahin ang lumang talahanayan gamit ang DROP TABLE.
Ang isa pang kritikal na senaryo ay ang pagdaragdag ng isang column HINDI NULL na walang default na halaga sa isang talahanayan na mayroon nang mga tala. Dahil hindi ito direktang pinapayagan ng SQLite, dapat kang lumikha ng isang pansamantalang talahanayan na may pansamantalang default na halaga, ilipat ang data, burahin ang orihinal, at palitan ang pangalan ng pansamantalang talahanayan sa pangwakas.
Pagtitiyak ng katatagan: Pagsubok at Iskematika
Huwag maglunsad ng paglipat sa produksyon nang hindi ito sinusubukan. Ang Room ang nagbibigay ng tool. pagsubok sa silid at ang klase ng MigrationTestHelper. Gamit ito, maaari kang lumikha ng database sa lumang bersyon, maglagay ng totoong datos, at pagkatapos ay patakbuhin ang runMigrationsAndValidate() upang mapatunayan na ang pinal na iskema ay ayon sa inaasahan at naroon pa rin ang datos.
Para maging praktikal ang lahat ng ito, mahalagang pamahalaan ang mga JSON file ng schema. Pag-configure ng Lokasyon ng silid.eskema Sa Gradle file, bubuo ang Room ng history ng bersyon. Ang mga file na ito ang ganap na katotohanan: ang field createSql Ang JSON mismo ang dapat mong kopyahin sa iyong mga manu-manong paglipat upang maiwasan ang mga pagkakaiba.
Paglipat mula sa purong SQLite patungong Room
Kung galing ka sa tradisyonal na paggamit ng SQLite, ang paglipat sa Room ay lubhang kapaki-pakinabang. Ang proseso ay kinabibilangan ng pag-convert ng iyong mga modelo sa @EntidadMagtakda ng mga DAO para palitan ang iyong mga manu-manong query at lumikha ng isang klase na nagpapalawak sa RoomDatabase. Mahalagang dagdagan ang bersyon ng database at tukuyin ang isang landas ng migrasyon, kahit na ito ay walang laman, upang hindi mabura ng Room ang umiiral na data kapag kinuha nito ang kontrol.
Ang pagiging dalubhasa sa siklo ng buhay ng schema, mula sa pag-export ng JSON at pagsulat ng tumpak na SQL hanggang sa pagpapatunay sa pamamagitan ng mga instrumented test, ay nagbibigay-daan sa application na umunlad nang walang takot na masira ang karanasan ng user o mawala ang mahalagang impormasyon sa device. Ibahagi ang impormasyong ito upang mas maraming tao ang matuto tungkol sa paksa.