PHP 5.5

OOP ir paprasto? Tartum, OOP kažkuom nepaprastas. Bet kuriuo atveju jei žmogus padorus, tai viskas bus aprašyta funkcijose/procedūrose ir problemos jokios neturėtų būt :)

Tas paprastas turėjau omenyje procedūrinį programavimą.

Ne visas žinutes skaičiau kas čia prifantazuota, bet susidariau įspūdį, kad dauguma čia rašančių apie OOP, ActiveRecords nelabai teko girdėt. Dabar yra tokie laikai kai metodai, pvz:

->select('*');
->get('table');
->join()

ir t.t. kur sugeneruoja reikalingą užklausą pagal nustatytą DB Draiverį. Atsiprašau jei įžūliai nuskambės, bet rašyti tokius dalykus kaip mysql_connect/mysql_query ir panašias funkcijas yra mažų mažiausiai kvaila kai yra pilna įvairiausių Frameworkų, ir įvairiausių bibliotekų kurios sumažina kodą N kartų, išsaugo performance.

Pasikeitei DB Draiverį iš mysql į kokį pdo ir visiškai dzin kokia PHP versija. Tos pačios užklausos -> toks pat rezultatas

Ne visas žinutes skaičiau kas čia prifantazuota, bet susidariau įspūdį, kad dauguma čia rašančių apie OOP, ActiveRecords nelabai teko girdėt. Dabar yra tokie laikai kai metodai, pvz:

 

->select('*');
->get('table');
->join()

 

ir t.t. kur sugeneruoja reikalingą užklausą pagal nustatytą DB Draiverį. Atsiprašau jei įžūliai nuskambės, bet rašyti tokius dalykus kaip mysql_connect/mysql_query ir panašias funkcijas yra mažų mažiausiai kvaila kai yra pilna įvairiausių Frameworkų, ir įvairiausių bibliotekų kurios sumažina kodą N kartų, išsaugo performance.

 

Pasikeitei DB Draiverį iš mysql į kokį pdo ir visiškai dzin kokia PHP versija. Tos pačios užklausos -> toks pat rezultatas

Netiesa, tavo AR tiktai generuoja querius ir tiek – apačioje vis tiek stovi kažkoks driveris, kuriuo naudojasi AR ir taip lengvai nepakeisi. Aišku, nieks nerašytų tokių rimtų dalykų ant ext/mysql, bet faktas tas, kad jei taip nutiktų, tai lygiai taip pat būtų E_DEPRECATED ir AR kūrėjams reiktų keisti tą... :)

O dar grįžtant apie PDO, kaip išvesti klaidas, jeigu darau kokį sql užklausą? Nes įšeina padaryti, kad rodytų, kad tiktai, jeigu blogai suvedi duomenis prie mysql prisijungimo

Turi nustatyti exception'us:

http://php.net/manual/en/pdo.error-handling.php

http://php.net/manual/en/class.pdoexception.php

O dar grįžtant apie PDO, kaip išvesti klaidas, jeigu darau kokį sql užklausą? Nes įšeina padaryti, kad rodytų, kad tiktai, jeigu blogai suvedi duomenis prie mysql prisijungimo

http://php.net/manual/en/pdo.connections.php #2 pavyzdys, jei connectionas nepavyksta – meta PDOException.

Bet tas PDO kažkaip sudėtingai atrodo :D.

Bet tas PDO kažkaip sudėtingai atrodo :D.

Kas būtent? Labai gražus objektinis API, prie ko apskritai juda PHP daugybėje savo bibliotekų. Daug geriau, negu, pavyzdžiui http://phpsadness.com/sad/4 :)

Kas būtent? Labai gražus objektinis API, prie ko apskritai juda PHP daugybėje savo bibliotekų. Daug geriau, negu, pavyzdžiui http://phpsadness.com/sad/4 :)

Na aš asmeniškai jau buvau pripratęs prie mySQL, be jokių PDO ir pnš, dabar bus sunku priprast. Tarkim šitos eilutės įdomiai atrodo (Paryškintos)

$stmt = $db->prepare('INSERT INTO users SET name = :name, email = :email');

// Parametrų reikšmės nustatomos atskirai

$stmt->bindParam(':name', $_POST['name'], PDO::PARAM_STR);

$stmt->bindParam(':email', $_POST['email'], PDO::PARAM_STR);

// Vykdoma užklausa

$stmt->execute();

// Gaunam eilutės ID

$user_id = $db->lastInsertId();

Na, viskas normalu – nurodai, kuris argumentas, jo reikšmę, ir kaip bindint (int/string ir t.t. (nes PHP tie tipai labai lengvai kaitaliojasi, kartais gali padaryti ne tą)). Su ext/mysql duodavai tik pačią reikšmę, todėl tekdavo prijungti į stringą pačiam (t.y. gali padaryti klaidą tame) + escapinimas nepadeda ne-string tipams (escapinami tik apostrofai ir panašūs dalykai – injekciją galima padaryti ir be jų) :)

T.y. šitos funkcijos nelabai kur sutrumpinsi ir ji yra „apie viską pagalvota“. real_escape nebūdavo pilnavertė to alternatyva, todėl ir atrodo, kad kodo mažiau.

--

Kai visos reikšmės yra stringai, galima naudoti ir http://www.php.net/manual/en/pdostatement.execute.php iškart su argumentais, tada kiek mažiau kodo gaunasi.

Sprunkas, naudok mysqli ir bus gerai :)

Bet tas PDO kažkaip sudėtingai atrodo :D.

Nu aš pvz greit pramokau jį, reikia tirsiog pradėti nuo smulkių, kaip įrašymas, kaip atvaizdavimas su juo rašosi ir t.t.

Bet šiaip gali ir mysqli naudoti. Google: mysqli procedural

Nu aš pvz greit pramokau jį, reikia tirsiog pradėti nuo smulkių, kaip įrašymas, kaip atvaizdavimas su juo rašosi ir t.t.

Bet šiaip gali ir mysqli naudoti. Google: mysqli procedural

O skyriasi jie? Nuo PDO? t.y saugumo spragomis ir pnš?

O skyriasi jie? Nuo PDO? t.y saugumo spragomis ir pnš?

Pagrindinis esminis skirtumas tarp PDO ir MySQLi turbūt tas, kad PDO palaiko 12 skirtingų duombazių, o MySQLi tik vieną. Daugiau info čia.

GitHub'e jau stovi galutinė PHP 5.5 NEWS versija :)

https://github.com/php/php-src/blob/php-5.5.0/NEWS

Tai kaip supratau, geriau biškeli daugiau pavargti, bet pereiti ant PDO, o ne MYSQLi ? Ateičiai ir tobulėjimui būtų į naudą.

Tai kaip supratau, geriau biškeli daugiau pavargti, bet pereiti ant PDO, o ne MYSQLi ? Ateičiai ir tobulėjimui būtų į naudą.

Toks ten ir vargimas.

http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers

Viskas gražiai aprašyta, aš pvz greit išmokau

Tai kaip supratau, geriau biškeli daugiau pavargti, bet pereiti ant PDO, o ne MYSQLi ? Ateičiai ir tobulėjimui būtų į naudą.

PDO pagrindinė galimybė – ne vien mysql (su kuria įvairių „pokštų“ pastaruoju metu vyksta), bet ir kitų duomenų bazių prieiga.

T.y. tarkim tu pereini prie PostgreSQL, su PDO tau reikia pakeisti vieną eilutę, kur surašyti prisijungimo duomenis, taip pat galbūt kažkiek modifikuoti sudėtingesnes užklausas.

Su mysqli tau reiktų pakeisti kiekvieną eilutę, kur dirbama su DB. Turbūt eitų ir automatiškai, bet vis tiek... :)

Toks ten ir vargimas.

http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers

Viskas gražiai aprašyta, aš pvz greit išmokau

Dėkui už info. Susipažinimui - kaip tik!

del kokiu nescapintu kabuciu trida paleido

Pamokėlė apie naująją slaptažodžių hash'inimo API (kuri defaultu naudoja bcrypt): kaip sugeneruoti hash'ą, patvirtinti, ar jis sutampa su slaptažodžiu ir t.t.

Creating and Verifying Hashes in PHP, The Easy Way

Pamokėlė apie naująją slaptažodžių hash'inimo API (kuri defaultu naudoja bcrypt): kaip sugeneruoti hash'ą, patvirtinti, ar jis sutampa su slaptažodžiu ir t.t.

 

Creating and Verifying Hashes in PHP, The Easy Way

O dabar man kilo vienas toks klausimas, ar jis taip pat vertas dėmėsio, kaip ir kiti slaptažodžių hash'inimo API, kur tu pasirašęs savo paraše? Ar išvis rekomenduoja dabar tik šitą naudot?

P.S Dėl PDO prepared statments:

Ar nieko blogo jeigu INSERT, DELETE, UPDATE, SELECT užklausose naudosiu visada prepared statments, ar nenukentės kodas ir pnš?

O dabar man kilo vienas toks klausimas, ar jis taip pat vertas dėmėsio, kaip ir kiti slaptažodžių hash'inimo API, kur tu pasirašęs savo paraše? Ar išvis rekomenduoja dabar tik šitą naudot?

 

P.S Dėl PDO prepared statments:

Ar nieko blogo jeigu INSERT, DELETE, UPDATE, SELECT užklausose naudosiu visada prepared statments, ar nenukentės kodas ir pnš?

Kaip sakiau, password_* funkcijos naudoja Bcrypt, kuria ir miniu savo paraše – tai viena iš tinkamų, lėtų hash funkcijų.

Dėl prepared statements, tu ir TURI visad juos naudoti, kai užklausose yra kintami parametrai. Kas gi gali nukentėti...

Kaip sakiau, password_* funkcijos naudoja Bcrypt, kuria ir miniu savo paraše – tai viena iš tinkamų, lėtų hash funkcijų.

 

Dėl prepared statements, tu ir TURI visad juos naudoti, kai užklausose yra kintami parametrai. Kas gi gali nukentėti...

Tą prasme lėta hash funkcija?

P.S Nukentėti, tai turėjau omeny, krovimo greitį ir t.t

Tą prasme lėta hash funkcija?

 

P.S Nukentėti, tai turėjau omeny, krovimo greitį ir t.t

Trys žodžiai, kurio nesupranti? Ar kodėl slaptažodžius hešuoti reikia būtent lėta funkcija?

Paskaityk http://throwingfire.com/storing-passwords-securely/

TL;DR: Jei greitai pagaminamas hash'as, greit tikrins juos ir įsilaužėlis :)

Ten dar mini ir constant-time comparison: tai nėra kritinis dalykas, bet retais atvejais gali būti šiokia tokia saugumo bėdelė. password_verify() turėtų būtent naudoti constant-time comparison, jei nelyginsi pats hashų su == ar ===, manau, būsi saugus ir nuo to :)

Dėl prepared statements: taip, tikriausiai jie veikia lėčiau. Bet užtikrinčiau. Ir žinai ką, verta nepamiršti dviejų taisyklių:

Premature optimization sucks

Micro-optimization is [usually] stupid

Rimtai. Tu neprogramuoji poros MHz mikrokontroleriui. Jei tinklalapis performina gerai, tai gerai, jei ne – tada ieškai kaltininkų (bottleneckų) su profileriu ir taisai tai (ir esu labai užtikrintas, kad kaltė bus tavo, o ne PDO :)). Manau, kad prepared statements atidirbti gerai ir sukurti kiek įmanoma greitesni (tuo labiau, jei išjungi emuliavimą (ATTR_EMULATE_PREPARES) ir preparinimą už tave atlieka duomenų bazė).

Aišku, jei užklausa visada su tais pačiais parametrais – gali tiesiog hardcodinti. Bet jei ne, tada tikriausiai reiktų naudoti prep statements, nesvarbu, ar parametrus duodi pats, ar vartotojas.