Jump to content
php.lv forumi

Migrācijas - jā vai nē


qwerty

Recommended Posts

Laikam jāsadala jēdziens migrācijas.

Datu migrācijas un shēmas migrācijas. Saprotams ka lai sistēma strādātu vajadzīgi abi. 

Ar tiem freimvorkiem kuriem esmu strādājis, šīs abas migrācijas nodrošina viens mehānisms, tātad - migrācijas. 

Ja gribi nodalīt, uztaisi 2 migrācijas failus, shēmai un datiem. 

 

  • Piemērs kautvai ar lietotāju grupām. 

  • Jauna fīča - tagad lietotāji būs sadalīti pa grupām. Loģiski vajadzīga grupu tabula (shēmas migrācija), vajadzīgas kautkāda defaultās grupas (datu migrācija) un jāsamet tie lietotāji pie pa grupām (datu migrācija).

Viss šis pasākumu kopums, joprojām definējas kā migrācija. 

 


 

 

Manuprāt ražot kaut kādus datus devā kurus pēc tam baksta prodā ar migrāciju ir diezgan nesmuki. Thats all. 

 

  • Kurš šajā gadijumā tad tev sabakstīs šos datus? Lietotājs nedrīks būt bez grupas! 20 grupas un 10000 lietotāji? 


     

Link to comment
Share on other sites

  • Replies 32
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Jā.

 

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

 

Jāpiekrīt trollim.

Link to comment
Share on other sites

Kurš šajā gadijumā tad tev sabakstīs šos datus? Lietotājs nedrīks būt bez grupas! 20 grupas un 10000 lietotāji?

Default to all, admin vienam un tas lai tālāk darbojas caur paneli. Nevis tu tagad devojot domāsi, ko kur likt.
Link to comment
Share on other sites

 

 

Default to all, admin vienam un tas lai tālāk darbojas caur paneli. Nevis tu tagad devojot domāsi, ko kur likt. 

Admin vienam, default to all. Kautkāds WTF vai arī neesi iebraucis par ko vispār ir runa.  

Uzraksti man tabulas user_group(user_id, group_id) create sql kas šo visu izdara (protams bez selektiem no users/groups un insertiem user_group) un šī tēma bus slēgta. 

Link to comment
Share on other sites

  • Jauna fīča - tagad lietotāji būs sadalīti pa grupām. Loģiski vajadzīga grupu tabula (shēmas migrācija), vajadzīgas kautkāda defaultās grupas (datu migrācija) un jāsamet tie lietotāji pie pa grupām (datu migrācija)
  1. Lietotāji tev jau eksistē;
  2. Pēc migrācijas shēmā ir grupu dalījums, pēc noklusējuma visi lietotāji var būt vispār bez grupas ar ACL defaultiem (deny everythang, permit nothang);
  3. Lietotāji vispār netiek aiztikti (o2m relācija);
  4. Admins ielien panelī un sadala aitas (lietotājus) grupās;
  5. ?!! Profit

Konkrētajā piemērā, tas vispār nav tavā kompetencē gar konkrētajiem datiem gramstīties.

Edited by F3llony
Link to comment
Share on other sites

Nē, tas ir tieši šī argumenta scope, jo runa ir par arhitektūru un arhitektūra ir development scope, tā pat, kā migrācijas. Ja tev ir ACL modelis, kas nepieļauj lietotājus bez grupas ar noklusējuma rules kodā, tad tava arhitektūra ir kretīnisms un tu mēģini tagad ieborēt, ka tevis paša radītā hipotētiskā problēma ir arguments par to, kāpēc vajadzētu bāzt šādus datus migrācijās.

 

Jebkurā gadījumā, tev kā devam nav nekādas ziņas, kādās kurš grupās tiks iedalīts, jo tas nav arhitektūras jautājums. Case closed, go home. 

Link to comment
Share on other sites

Uzraksti man tabulas user_group(user_id, group_id) create sql kas šo visu izdara (protams bez selektiem no users/groups un insertiem user_group) un šī tēma bus slēgta.

Nekāds CREATE TABLE to neizdarīs, kā arī tam nemaz to nav jādara.

 

Ja tev obligāti vajag, lai lietotjājs ir [vismaz] vienā grupā, tad pēc tabulas izveides tev ir jāpalaiž skripts, kas visus userus samet tajā default grupā.

Link to comment
Share on other sites

 

 

Nē, tas ir tieši šī argumenta scope

Labi, lai Tev būtu vienkāršāk runāsim objektos. Ir objekts A, ir objekts B. Ir relācija ka vienam A ir vismaz viens vai vairāki B. 

A jau eksistē datubāzē, B ir jauns un tiek izveidots ar CREATE TABLE. Kā tiks nodrošināta relācija pie sistēmas update? 

Lūdzu konkrēts gadījums, A un B var būt whatever kas, bet relācija ir obligāta.

 

 

 

 

ad pēc tabulas izveides tev ir jāpalaiž skripts

 

un tas jau būs kautkas cits nevis datu migrācija vai ne? 

Link to comment
Share on other sites

A jau eksistē, bet B vēl neeksistē. Tāpēc tev nevar būt relācija starp A un B, jo relācija prasa kā minimums 2 objektus, starp kuriem veidot relāciju. Ja tev ir bars ar lietotājiem, ir izveidota grupu konstrukcija, bet grupas vēl neeksistē, loģiski, ka nekāda relācija nesanāks. Grupas veidot nav developera pienākums, tātad nekādas datu migrācijas šā vai tā nebūs, savukārt nākotnes relācijas veidosies organiski, savukārt jaunām organiskām relācijām nekādas migrācijas nav nepieciešamas. Konkrētais princips darbojas +/- jebkurā gadījumā. 

 

Pie tam, tavs B ir nevis objekts, bet objektu kolekcija, un pats relācijas princips padara tavu piemēru par bezjēdzīgu un relācija nav obligāta, jo tas, ka relācija nav obligāta ir jāparedz arhitektūrā. Ja tu esi aiz sava prieka padarījis to relāciju obligātu saistot kaut ko, kas eksistē, ar kaut ko, kas neeksistē, cmoon... 

Link to comment
Share on other sites

Vienkāršāks piemērs - Ir raksti ar komentāriem. Vecajā versijā komentāri katru reizi tiek skaitīti ar COUNT, jaunajā, katram rakstam komentāru skaits glabājas rakstu tabulā. Uz prod jau ir raksti, tāpēc pēc shēmas izmaiņas ir jāpalaiž migrācijas skripts, kurš saskaita komentāru skaitu katram rakstam un ieraksta rakstu tabulā.

Link to comment
Share on other sites

Jā, un šis piemērs ir pilnīgi valids, jo tu neizzīd no pārpilnības raga kaut kādus datus, bet gan paņem datubāzē jau esošu informāciju un konvertē saskaņā ar jauno shēmu. Šāda darbība ir pilnīgi saderīga ar manis teikto, jo šajā gadījumā migrācija neražo jaunus datus - tā pārveido esošo datu glabāšanas veidu/uzskaiti/reprezentāciju, pie tam to izdara neko nejēdzot par pašiem datiem izņemot to shēmu.

Link to comment
Share on other sites

 

 

A jau eksistē, bet B vēl neeksistē. Tāpēc tev nevar būt relācija starp A un B, jo relācija prasa kā minimums 2 objektu

Update brīdī būs 2 objekti. Shēmas migrācija izveidos B, kurš izveidos relāciju?

 

Tu atkal mēģini vienkāršu uzdevumu pārdefinēt tā lai tas iekļautos Tavā "risinājumā". 

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