Blitz

Datu bāzes objekti a.k.a tabulas ieraksti. B objektu definē prasības (klients, lietotājs). Viena datu migrācija izveidos šos "defaultos" B objektus, otra - relācijas starp A un B. Piemēram klients grib lai lietotāji grupētos viņam 3 grupās un nodefinē tās - "Basic user, advanced user, admin user." Tad vēl viņs saka ka, lietotājam ir jāpieder kādai no šīm grupām lai redzētu atbilstošās fīčas. Tas viss protams menedžējams caur paneli ko redz tikai "admin user" grupas lietotāji. Papildus klients pasaka, ka advanced useri defaultā ir visi tie kam izpildās kritērijs X, admin useri kam kritērijs Y, pārējie ir basic useri. Tagad esmu uzrakstījis shēmas migrāciju, create table groups, create table user_groups. Palaižu update, saku klientam ka viss ok. Ko tālāk, kas notiek?

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

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. un tas jau būs kautkas cits nevis datu migrācija vai ne?

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.

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.

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. Kurš šajā gadijumā tad tev sabakstīs šos datus? Lietotājs nedrīks būt bez grupas! 20 grupas un 10000 lietotāji?

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.

Konfigurācija, klasifikatori, vārdnīcas. Daudz kas var glabaties datu baze un lai piegadatu izmainas vajag migracijas. Atkarigs no sistēmas.

Migrācijas var saturēt ne tikai shēmas migrācijas bet arī datu migrācijas. Tad jadumpo visa datubaze.

(facepalm)

Tādā normālā gadījumā kur sistēmai var būt n-vides, un developerim ir pieeja tikai savai dev videi. Uzstādīšanu un konfigurēšanu citās vidēs veic admins, izmantojot instrukciju un konfigurācijas failus. Ja to nevar izdarīt tad ir vai nu sūdīga konfigurācija, sūdīga dokumentācija vai sūdīgs admins.

Janem vērā ka konfigurācijas lietotāji pārsvarā ir admini, normālā gadījumā. Klašu konstantes, metodes varētu nebut tas lasamakais gabals adminam, un viņš pārsvarā lieto melno konsoli nevis ide. Assoc masīvi manuprāt labākais veids ka glabāt konfigu. Ar pieraksta veidu var variet iegūstot lasamibu, inheritance ar array_merge utt

ja projects_details_load satur kādu ajax izsaukumu, tad ajax izsaukumam ir jāpieliek parametrs async=false http://api.jquery.com/jquery.ajax/

Jebkura (gandrīz) gramatvedības sistēma piedāvā rēķinu eksportu uz banku (izmaksa no konta). Pieņemu ka Tavai PHP sistēmai jāstrādā tieši pēc tāda paša principa. http://help.dnb.lv/lv/internet-office/Manual/banka/maksajumi/import/ Par to iemaksu kontā, gan nav skaidrs ko domā. Darbojoties ar kontu tu no tā vari tikai kautko aizskaitīt.

http://www.php.net//manual/en/function.isset.php http://lv1.php.net/manual/en/function.empty.php Ja liekas ka visi kautko pīpē - http://lv1.php.net/get-involved.php

atkarīgs no datu daudzuma ko tam php būs "jālūpo".

Rekur neklātienē iespējams: http://www.biznesakoledza.lv/studiju_iespejas/informacijas_tehnologijas/

Paldies, skaidrs, viss izskatas vienkarshi nemot verā ka VCS vispar nav nekad aiztikts. Nu tas vairāk kā dev vide, kur patestēt kodu pirms push

Kā vispār praksē tiek darīts ja kods stāv iekš github vai bitbucket? Pašlaik izskatās ka viss GIT ieviešanas un izstrades proces ir šāds: 1) Uztaisam savu lokalo webserveri uz savas dev kastes ar tādu konfigu kā production serveris. 2) Nokopejam no production servera failus uz dev kastes kur stradasim ar GIT 3) Izveidojam repo iekš github 4) uztaisam push visus projekta failus uz Github 5) uztaisam pull lai savaktu jaunako no github 6) labojam, testejam, commitojam lokali 7) atkartojam 4 soli Kad ir gatavs tad vienkrshi downloado visus failus no github un kopē uz production servera?

Nu tas lokāli vairāk testam, jo reposotorijs dzīmē atradīsies kautkru citur, gribu pēc standarta dabūt failus, padarboties un commitot uz servera. Respektīvi eksistējošam projektam pieslegt versiju kontroli. + laikam sapratu, tādām vajadzībām bez github neiztikt

augstāk minēts

Nevienu failu tur neredzu.

Sāku bakstīt GIT, bet kautkā nesanāk (trūkst izpratnes). Tātad ir doma ka stāv kautkāds projekts X (testam 1 fails) mapē D:/wwwroot/repo_remote/file.php Pirmais pēc manuāļa ko daru konsolee ir, $ cd D:/wwwroot/repo_remote $ ls file.php $ git init Pēc tam cik saprotu, man ir jānoklonē šī repo lai varu darboties lokāli. $ cd D: $ mkdir local $ cd local $ git clone D:/wwwroot/repo_remote Cloning into 'repo_remote'... warning: You appear to have cloned an empty repository. done. Rezultātā tas fails file.php nenokopējas. Kā lai ievācu visu kas ir D:/wwwroot/repo_remote savā lokālajā repo un varu sākt strādāt?

Vienīgais CI neatļauj čeinot random secibā, jo pēc update/insert/delete izsaukuma tiek uzreiz izpildits kverijs. Un varbūt labi vien ir.