briedis

Esi sveicināts civilizētā pasaulē :D Skaidrs ir viens, ka vietējie kantori nekad nespēs izkonkurēt tādus lielos džekus, kam sistēma atstrādāta un ieguldīts nevājš resurss, lai viss strādātu. Salīdzināt jau nevar shared hostu ar individuālu hostu, kas zin kas tur griežas uz tās kastes fonā.

Serveris ir kaut kāds monstrs? Kāpēc nelieto virtuālo? Pa 60 eur, man liekas, var diezgan zolīdu konfigurāciju dabūt. Varbūt arī pasaulē populāri vhosti nebūs tādi ņuņņas kā vietējie kantori :)

Man tev tiešām ir sliktas ziņas :)

Nevajag glabāt pa kaut kādām useru direktorjām. Kas notiek, ja useris pamaina vārdu? Pārāk liels čakars 1. Failu nosauc md5(uniqid()); // 2. Saglabā datubāzē: userId, faila_hash, faila_istais_vards Uzraksti funkciju, kas, saņemot to hashu, atgriež faila pilno ceļu, piemēram: function getFilenameFromHash($hash){ return '/upload/' . substr($hash, 0, 2) . '/' . $hash; } 3. Izveido mapi kur glabā failu mkdir(dirname(getFilenameFromHash($hash)); 4. Saglabā pašu failu uz konkrēto ceļu: move_uploaded_file(...) Lai lejuplādētu failu, uzraksta php skriptu, kam padod GET parametros kuru failu vajag, un skripts viņu dod ārā lejuplādēšanai: http://php.net/manual/en/function.readfile.php

1. http://stackoverflow.com/questions/1330693/validate-username-as-alphanumeric-with-underscores 2. Ķidā sīkāk pa solim.

Kaut kādas basic lietotāju grupas, saraksts ar valstīm, geoip figņas. Principā, neredzu problēmu tam, ka šie dati varētu iet kopā ar migrācijām.

Nevar tā pateikt, cik sarežģīti, jo tas atkarīgs no zināšanu līmeņa. Kāds to visu varētu uztaisīt vienā, divās dienā, citam paies divas nedēļas.. Sāc pa druskai - izveido lietotāju tabulu, uztaisi reģistrācijas formu, utt. Sāc mācīties mysql. Kad rodas konkrēti jautājumi, droši vari rakstīt šeit, gan jau atradīsies kāds, kas palīdzēs.

Fellony, bet kā bez vecajām migrācijām tu pacelsi jaunu vidi? Tad bez maz vajag kaut kādu rīku, kas samerdžo vecās migrācijās vienā migrācijā, bet tas kaut kā neliekas racionāli. Redzu problēmu tad, ja ir miljons migrācijas un mēs gribam testēt ar reālu db - tad sanāk, ka testi iebremzē, jo daudzās migrācijas parasa ilgāku laiku...

Codez, kā izpaužas deployments un rollbacks? Man ar laravel sanāk tā: 1. Uzrakstu migrāciju (+ atbilstošu orm klasi/modeli izveidoju) 2. Iekomitoju, uzpušoju 3. Uz servera no pulloju 4. Palaižu php artisan migrate komandu 5. Ja kaut kas nepatīk - php artisan migrate:rollback un revertoju git'u Migrācijas izskatās ~ šādas: Tabulas veidošana: https://gist.github.com/briedis/2f82507db61720707ff0 Kolonnu pielikšana: https://gist.github.com/briedis/57612abce4c4ad69cd77 Laravelam ir koda ģenerētājs, kas ar 1 komandu uztaisa šablonu migrācijai: php artisan migrate:make create_table_foobar => https://gist.github.com/briedis/218e40aad3e2b1df66b8 Šajā gadījumā gan sanāk otrādāk - mēs veidojam vispirms migrāciju, tikai pēc tam veidojam modeli.

Migrācijas tāpat tu vienmēr testē lokāli, tāpēc jocīgi, ka var sanākt feilošana. Bez migrācijām vai tad būtu labāk? Tāpat tu vari uzrakstīt nepareizu sql skriptu, tāpat kaut kas var nofeilot un var sanākt aizture. Kā tu dalīsies ar citiem deviem ar izmaiņām? Tagad easy - uzraksti migrāciju, iekomito, un pārējiem vien atliek uzrakstīt artisan migrate. Bez migrācijām noteikti būtu kaifs meklēt ar roku, kuri sql ir jāizpilda, kuri nē, un kurā brīdī kods (versiju kontrolē) atbilst kādam datubāzes stāvoklim. Migrācijas neatrisina visas problēmas, tikai ievērojami atvieglo dzīvi, kad vajag dalīties ar shēmām, replicēt izstrādes vides utt. Migrācijas ideāli noder arī, ja gribma integrācijas testus uzrakstīt - plaižam migrāciju, uzbūvēmaj testa DB un laižam testus. Pēc testa - dropojam db. Tik vienkārši. Gribētu redzēt, kā to realizētu bez migrācijām...

It depends. Jo Indekss nestrādā pilnvērtīgi (sešdemit OR'i ar indeksiem nav tas labākais). Joins, protams, būtu ātrāks. Bet, es ļoti šaubos, vai šajā gadījumā tas ir tik būtiski, un nevajag aizrauties ar optimizācijām pirms laika.

Visdrīzāk tev ir veca php versija un neatbalsta īso ternary pierakstu. Risinājums: $file = $_REQUEST['file'] ? $_REQUEST['file'] : 'images/';

Ar group_concat jāuzmanā, jo viņam ir limits, pēc kura vnk vērtības tiek nogrieztas.

Bitītmatos, apskaties kas tur ir tajā rindiņā! "uploader.php on line 32"

Nu 60 jau ir figņa... Galvenais, lai ir indekss tai kolonnai.

Tiešām, tiešām vajag 1k objektus? Izklausās jocīgi...

+ ja gribi uzlabot kaut nedaudz kodu, tad iznes šo daļu atsevišķā funkcijā: if(login()){ $mid = mysql_real_escape_string($_COOKIE['member_id']); $qwery = mysql_query("SELECT member_group_id FROM ".prefx."members WHERE member_id = '$mid' AND member_group_id = '4'") or die(mysql_error()); if(mysql_num_rows($qwery)==1){ return true; }else{ return false; } } Funkcijai ir divi parametri - member id un group_id. Funkciju nosauc tā - function isMemberIngroupd($memberId, $groupId); Tālāk vari izlabot vecās funkcijas: function isAdmin(){ return isMemberInGroup($_SESSION['mid'], 4); } utt... Attiecīgi, ja tev tagad būs kaut kas jāmaina, tad tas nebūs jādara 3 vietās, bet gan tikai 1 vietā. Atceries vienu no SVARĪGĀKAJIEM noteikumiem - DONT REPEAT YOURSELF (jeb DRY) Tiklīdz tu raksti/kopē vienu un to pašu kodu divās vai vairāk vietās - IZNES TO KODU ATSEVIŠĶĀ METODĒ/FUNKCIJĀ! Piekopjot šo vienkāršo principu, tavs kods būs 10x labāks un 10x mazāk tiks pieļautas kļūdas. + kods būs īsāks, protams

Nu vismaz neglabā cepumā to ID, bet gan iekš $_SESSION. Tad nevarēs tik vienkārši pamainīt to ID.

Nu ja ļoti sāpīgi izdomāt, Tu vienmēr vari atlasīt ierakstus, izķeksēt ārā masīvu ar ID, un atlasīt atsevišķi ar vienu selectu whereIn('id', $ids); Man pat parasti patīk tā darīt, jo tad viss ir skaidri saprotams, nenotiek nekāda maģija ar ORMa join'iem utt.

Man liekas, ka ar šo biju saskāries, bet neatceros, kā atrisināju :) Varbūt šeit ir atbilde: http://stackoverflow.com/questions/19852927/get-specific-columns-using-with-function-in-laravel-eloquent Noteikti, ka var atrast kko šeit: https://www.google.lv/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=eloquent+specify+column+with

Nu tad sanāk tas pats. Mysql pieejamāks, tas jau kā standarts. + 90% koderu pirmā pieredze būs ar mysql, nevis postgre...

Domā viņam ir indekss datumam? Domā, ka viņam ir simtiem tūkstošu ierakstu? Domā, ka viņš vispār kādreiz ir izmantojis EXPLAIN?

Tas tā kā jautāt, kāpēc pie mums vairāk brauc ar opeļiem, nevis škodām.

SELECT WHERE DATE(datuma_kolonna) = 2014-12-29

Associatīvie masīvi sux, ļaunuma sakne. Klašu instances rulez vienmēr, IDE power!