qwerty Posted January 3, 2015 Report Share Posted January 3, 2015 Nespēju saprast vai man no DB migrācijām ir lielāks labums vai posts. Teorētiski ir skaidri saglabāti soļi kas un kā darīts ar tabulām un kā šos soļus atcelt, bet tajā pašā laikā vēlāk no šīs informācijas tāpat nav nekādas jēgas, jo nevienam parasti neinteresē kā DB izskatījās pirms mēneša vai diviem - viss iet tikai uz priekšu. Arī bieži rodas konflikti, kad līdz pusei nostrādājusi un nofeilojusi migrācija aizkavē. Ja jāveic kādas sarežģītākas izmaiņas, jāizmaina foreign keyi, tad migrāciju ->down() metožu uzrakstīšana ir gatavais murgs. Pilns up un down cikls ir diezgan lēns, sākot ar kādām 10 sekundēm. Dažreiz liekas, ka ērtāk būtu glabāt tikai shēmas dumpu no datubāzes. Bet man pieredze par mazu lai izsvērtu kura metode ilgtermiņā atmaksāsies. Viedokļi? Quote Link to comment Share on other sites More sharing options...
briedis Posted January 3, 2015 Report Share Posted January 3, 2015 Migrācijas tāpat tu vienmēr testē lokāli, tāpēc jocīgi, ka var sanākt feilošana. Bez migrācijām vai tad būtu labāk? Tāpat tu vari uzrakstīt nepareizu sql skriptu, tāpat kaut kas var nofeilot un var sanākt aizture. Kā tu dalīsies ar citiem deviem ar izmaiņām? Tagad easy - uzraksti migrāciju, iekomito, un pārējiem vien atliek uzrakstīt artisan migrate. Bez migrācijām noteikti būtu kaifs meklēt ar roku, kuri sql ir jāizpilda, kuri nē, un kurā brīdī kods (versiju kontrolē) atbilst kādam datubāzes stāvoklim. Migrācijas neatrisina visas problēmas, tikai ievērojami atvieglo dzīvi, kad vajag dalīties ar shēmām, replicēt izstrādes vides utt. Migrācijas ideāli noder arī, ja gribma integrācijas testus uzrakstīt - plaižam migrāciju, uzbūvēmaj testa DB un laižam testus. Pēc testa - dropojam db. Tik vienkārši. Gribētu redzēt, kā to realizētu bez migrācijām... Quote Link to comment Share on other sites More sharing options...
codez Posted January 3, 2015 Report Share Posted January 3, 2015 Es daru tā: Izmantoju ORM, ir modeļi, ir funkcionalitāte, kas var uzģenerēt modeļa pilnu create statementu, tālāk ir funkcionalitāte, kas māk uzģenerēt diferencei starp jebkuriem diviem create statementiem. Tas ļauj: 1)Uzģenerēt migrācijas automātiski; 2)Uzģenerēt migrācijas starp jebkuriem diviem stāvokļiem, lai paātrinātu procesu. Quote Link to comment Share on other sites More sharing options...
briedis Posted January 3, 2015 Report Share Posted January 3, 2015 Codez, kā izpaužas deployments un rollbacks? Man ar laravel sanāk tā:1. Uzrakstu migrāciju (+ atbilstošu orm klasi/modeli izveidoju) 2. Iekomitoju, uzpušoju 3. Uz servera no pulloju 4. Palaižu php artisan migrate komandu 5. Ja kaut kas nepatīk - php artisan migrate:rollback un revertoju git'u Migrācijas izskatās ~ šādas: Tabulas veidošana: https://gist.github.com/briedis/2f82507db61720707ff0 Kolonnu pielikšana: https://gist.github.com/briedis/57612abce4c4ad69cd77 Laravelam ir koda ģenerētājs, kas ar 1 komandu uztaisa šablonu migrācijai: php artisan migrate:make create_table_foobar => https://gist.github.com/briedis/218e40aad3e2b1df66b8 Šajā gadījumā gan sanāk otrādāk - mēs veidojam vispirms migrāciju, tikai pēc tam veidojam modeli. Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 3, 2015 Report Share Posted January 3, 2015 (edited) A kas tev liek glabāt miljards gadus vecas migrācijas? :< Reizi tur piemēram nedēļā vai 2ās, piem. sprinta beigās, shēma ir stabila, hands off un uztaisa tīrīšanu. Vecās migrācijas lai nīkst iekš GIT. Edited January 3, 2015 by F3llony Quote Link to comment Share on other sites More sharing options...
briedis Posted January 3, 2015 Report Share Posted January 3, 2015 Fellony, bet kā bez vecajām migrācijām tu pacelsi jaunu vidi? Tad bez maz vajag kaut kādu rīku, kas samerdžo vecās migrācijās vienā migrācijā, bet tas kaut kā neliekas racionāli. Redzu problēmu tad, ja ir miljons migrācijas un mēs gribam testēt ar reālu db - tad sanāk, ka testi iebremzē, jo daudzās migrācijas parasa ilgāku laiku... Quote Link to comment Share on other sites More sharing options...
codez Posted January 3, 2015 Report Share Posted January 3, 2015 briedi, migrāciju kontrolei izmantoju flyway visas migrācijas SQL formā glabājas versiju kontrolē. rollbacks tiek veikts ar backupu atjaunošanu kā to rekomendē paši flyway - lūk kā un pamatojums kāpēc. Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 3, 2015 Report Share Posted January 3, 2015 Kā, tas ir, pacelsi? Tev ir grūti uzrakstīt komandu, kas nodumpo aktuālo shēmu un atmet vecās migrācijas? Un kad vajag "pacelt", sāc no pēdējās aktuālās shēmas + migrācijas since then. Quote Link to comment Share on other sites More sharing options...
Blitz Posted January 4, 2015 Report Share Posted January 4, 2015 Migrācijas var saturēt ne tikai shēmas migrācijas bet arī datu migrācijas. Tad jadumpo visa datubaze. Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 4, 2015 Report Share Posted January 4, 2015 (edited) Nē, pilnīgi noteikti nē, bībelē ir punkts kas to aizliedz! Zaimotājs! Baigā atšķirība... Es gan protams spēcīgi iebilstu pret jebkādu datu glabāšanu migrācijās, jo why?! Edited January 4, 2015 by F3llony Quote Link to comment Share on other sites More sharing options...
Blitz Posted January 4, 2015 Report Share Posted January 4, 2015 Konfigurācija, klasifikatori, vārdnīcas. Daudz kas var glabaties datu baze un lai piegadatu izmainas vajag migracijas. Atkarigs no sistēmas. Quote Link to comment Share on other sites More sharing options...
briedis Posted January 4, 2015 Report Share Posted January 4, 2015 Baigā atšķirība... Es gan protams spēcīgi iebilstu pret jebkādu datu glabāšanu migrācijās, jo why?! Kaut kādas basic lietotāju grupas, saraksts ar valstīm, geoip figņas. Principā, neredzu problēmu tam, ka šie dati varētu iet kopā ar migrācijām. Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 4, 2015 Report Share Posted January 4, 2015 Teorētiski to protams var darīt, uztaisot kaut kādu "demo dati" migrāciju, bet es šādus datus glabātu kaut kā savādāk. Kaut SQL failā. Man gan šāda problēma ir reti, jo parasti sinhronizēju šādus datus no produkcijas lai dev būtu maksimāli tuvs prod. Quote Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share Posted January 5, 2015 Nē, tāpēc jau ari migrācijas freimvorkos neaprobezojas ar vienu shēmas sql failu vai datu sql failu. Tikpat labi shemai arī var būt viens sql fails ar create if not exists. Dati ir atkarīgi no shēmas tāpēc svarīgi lai izpilditos migrācija tieši tad kad viņai paredzēts izpildities. Otrs, šie dati ko satur migrācija var nebūt "demo dati" bet dati kas nepieciešami lai sistēma vispār strādātu, un tiem ir japiegadajas lidz ar update. Quote Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share Posted January 5, 2015 (edited) Dati ir atkarīgi no shēmas tāpēc svarīgi lai izpilditos migrācija tieši tad kad viņai paredzēts izpildities. Dati nav atkarīgi no shēmas, shēma ir atkarīga no datiem. Sāksim ar to. Vai arī tev lietotājvārdi, piemēram, tagad datubāzē glabāsies kā biginti, jo es tā esmu uzlicis? base8 encode FTW. Otrs, šie dati ko satur migrācija var nebūt "demo dati" bet dati kas nepieciešami lai sistēma vispār strādātu, un tiem ir japiegadajas lidz ar update. Bet kāpēc tu par visu varu gribi bāzt datus shēmas migrācijās? Nu labi, ja tev ir tādi dati, taisi atsevišķas datu migrācijas, Django style. Lai gan arī tur es neesmu redzējis, ka raw dati tiktu soursēti migrācijā, transformācijas, jā, bet dati? Konfigurācija, klasifikatori, vārdnīcas. Lai nu kā, man pat šie piemēri izskatās pēc datiem, kam nebūtu jābūt migrācijā, tiem būtu jātiek vilktiem no produkcijas. Tieši tādā pašā veidā, kad tu veido feature branch versiju kontrolē no master nevis FEATURE-XXX-STAGING un pēc tam dauzi galvu pret sienu, jo tavs feature branch ir branch no kaut kāda brancha, kam ar prod nav nekāda sakara. Šajā gadījumā, tev migrācijās būs dati, kam ar master/prod nav nekāda sakara. Es vēl joprojām pieturos pie tā, ka - Shēmas migrācijas ir tupas, tām nav jājēdz nekas par datiem, kas atrodas DB Datiem, kas atrodas dev db jānāk no produkcijas Datus no produkcijas fetcho ar skriptu Uz produkcijas datiem izpilda migrācijas, kas vēl nav produkcijā lai būtu konsistence ar citiem darboņiem Ar konkrēto pieeju nekad nav bijušas nekādas problēmas, konflikti, nesakritības vai vēl kaut kas. Dati vienmēr ir maksimāli tuvu produkcijai, konsistenti un paši agregē savas izmaiņas (talk about lietotāju grupas). Manuprāt ražot kaut kādus datus devā kurus pēc tam baksta prodā ar migrāciju ir diezgan nesmuki. Thats all. Edited January 5, 2015 by F3llony Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.