Jump to content
php.lv forumi

Migrācijas - jā vai nē


qwerty

Recommended Posts

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?

Link to comment
Share on other sites

  • Replies 32
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by F3llony
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by F3llony
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...