Blitz Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Kemito Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Kavacky Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share Posted January 5, 2015 Kā tas saprotams, nedrīkst? Argumentu studijā. Quote Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Kavacky Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
codez Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
F3llony Posted January 5, 2015 Report Share 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 Link to comment Share on other sites More sharing options...
Blitz Posted January 5, 2015 Report Share 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 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.