Blitz

 

 

Kādi 2 objekti, kādā update brīdī. 

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? 

 

 

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

 

 

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? 

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. 

 

 

pēc noklusējuma visi lietotāji var būt vispār bez grupas 

 

 

Lietotājs nedrīkst būt bez grupas!   

 

 

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. 

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? 

  
  

   

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)

 

 

kādā normālā gadījumā gar PHP aplikāciju konfigiem gramstās admini

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/

 

 

• algoritmu teorija,
• programmēšanas valodas,
• operāciju sistēmu programmēšana,
• Visual Basic,
• Visual Fortran,
• Pascal,
• C++ programmēšana,
• web programmēšana (PHP, MYSQL, XHTML, CSS, JavaScript, XML, JAVA),
• objektorientētā programmēšana,
• datortīklu programmēšana,
• datoru aparātnodrošinājuma, datu bāzes un datorproduktu projektēšana,
• sistēmadministrēšanas līdzekļu studēšana
• u.c.

Paldies, skaidrs, viss izskatas vienkarshi nemot verā ka VCS vispar nav nekad aiztikts.

 

 

Ko? Muļķības, tev nekādu lokālo webserveri nevajag priekš GIT.

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

 

 

 

That creates a directory named grit, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:

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.