Blitz Posted January 5, 2015 Report Posted January 5, 2015 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? Quote
Kemito Posted January 5, 2015 Report Posted January 5, 2015 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. Quote
Kavacky Posted January 5, 2015 Report Posted January 5, 2015 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. Quote
Blitz Posted January 5, 2015 Report Posted January 5, 2015 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. Quote
F3llony Posted January 5, 2015 Report Posted January 5, 2015 (edited) 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) Lietotāji tev jau eksistē; 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); Lietotāji vispār netiek aiztikti (o2m relācija); Admins ielien panelī un sadala aitas (lietotājus) grupās; ?!! Profit Konkrētajā piemērā, tas vispār nav tavā kompetencē gar konkrētajiem datiem gramstīties. Edited January 5, 2015 by F3llony Quote
Blitz Posted January 5, 2015 Report Posted January 5, 2015 (edited) pēc noklusējuma visi lietotāji var būt vispār bez grupas Lietotājs nedrīkst būt bez grupas! Edited January 5, 2015 by Blitz Quote
F3llony Posted January 5, 2015 Report Posted January 5, 2015 Kā tas saprotams, nedrīkst? Argumentu studijā. Quote
Blitz Posted January 5, 2015 Report Posted January 5, 2015 Kas tur nesaprotams. Ir konkrēts case, es prasu kā bez datu migrācijām to atrisināsi. Drīkst, nedrīkst, vajag, nevajag, glabāt datubāze vai hardkodēt tas ir ārpus šī piemēra scope. Quote
F3llony Posted January 5, 2015 Report Posted January 5, 2015 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. Quote
Kavacky Posted January 5, 2015 Report Posted January 5, 2015 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ā. Quote
Blitz Posted January 5, 2015 Report Posted January 5, 2015 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? Quote
F3llony Posted January 5, 2015 Report Posted January 5, 2015 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... Quote
codez Posted January 5, 2015 Report Posted January 5, 2015 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ā. Quote
F3llony Posted January 5, 2015 Report Posted January 5, 2015 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. Quote
Blitz Posted January 5, 2015 Report Posted January 5, 2015 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ā". Quote
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.