2. Fórumok
  3. Szoftverfejlesztés
  4. PHP programozás
  5. (kiemelt téma)
Keresés

Új hozzászólás Aktív témák

  • #14969 Sk8erPeter nagyúr pakriksz #14968
    Új Válasz #14969
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Sk8erPeter

    nagyúr

    válasz pakriksz #14968 üzenetére

    "Mint írtam, ha nincs benne azonos sor, akkor hozzá kell adni! Így az update nem jó ide."
    Bocs, igazad van, én voltam a hülye, kevertem a REPLACE INTO ... SET ...-szintaktikával... :W Ami egyből be is illeszti az új sort, ha nincs olyan még.
    De tulajdonképpen előnyt nem hoz ahhoz képest, amit most használsz, szóval a korábbit, amit írtam az UPDATE-tel kapcsolatban, inkább felejtsd el, bullshit, visszavonom.

    "» "INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
    ON DUPLICATE KEY UPDATE downloads = downloads + 1"
    Erre már ír hibát, méghozzá hogy "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':userip, :user, 1) ON DUPLICATE KEY UPDATE downloads = downloads + 1' at line 1""
    Azért az jó, hogy kihangsúlyoztam, hogy ezt direkt PDO prepared statement-es szintaktikával írtam, és hogy nézd meg, amit itt írtam... :)
    Nyilvánvaló, hogy ez így nem fog működni, amíg nem megfelelő módon használod.
    A :userip-nek és a :user-nek a query-ben szükséges egy megfeleltetés, értéket kell adni neki a query előkészítése után, így működnek a prepared statementek. Előnyük, hogy az SQL Injection általuk nem lehetséges.
    Direkt azért linkeltem be azt a hsz.-emet, mert ott írtam példákat, hogy lehet átírni PDO-sra a lekéréseket. :)

    De akkor berakom neked ide is, a saját példádhoz igazítva (ha el nem írom):

    // csatlakozás
    $db = new PDO(
    'mysql:host=localhost;dbname=test_db', // test_db-t módosítsd a megfelelő adatbázisnévre
    'root', // módosítsd
    '1234', // módosítsd
    array(
    PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;', // egyből UTF-8-ra fogja állítani kapcsolódás után a karakterkódolást
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // kivételeket fog dobálni probléma esetén
    )
    );

    $query = 'INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
    ON DUPLICATE KEY UPDATE downloads = downloads + 1';
    $stmt = $db->prepare ( $query );
    $stmt->bindValue( ':userip', $userip );
    $stmt->bindValue( ':user', $user );
    $stmt->execute();

    ez fog dobni egy exceptiont, amit try-catch-blokkal kellene lekezelned. A [B]rowCount[/B]-metódusra ez vonatkozik:
    http://hu1.php.net/manual/en/pdostatement.rowcount.php#109891
    "Daniel Karp ¶1 year ago
    Note that an INSERT ... ON DUPLICATE KEY UPDATE statement is not an INSERT statement, rowCount won't return the number or rows inserted or updated for such a statement. For MySQL, it will return 1 if the row is inserted, and 2 if it is updated, but that may not apply to other databases."

    Tehát ha a korábbi kód után írsz egy ilyet:

    $affected_rows = $stmt->rowCount();

    Akkor ezek szerint MySQL esetén az $affected_rows 1-et fog tartalmazni, ha új sor lett beszúrva, illetve 2-t, ha update-elve lett egy korábban már beillesztett sor.
    Így ellenőrizheted, mi a query-d eredménye.

  • #14967 Sk8erPeter nagyúr pakriksz #14965
    Új Válasz #14967
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Sk8erPeter

    nagyúr

    válasz pakriksz #14965 üzenetére

    Pont itt tettem fel a kérdést költőien, ezelőtt 3 hsz.-szel, hogy hogyan lehetséges, hogy a mai napig ennyi összefűzött query van a kódokban, mikor a normális tutorialok első helyen kellene, hogy felhívják a figyelmet rá, hogy ez így gáz.

    Ez a "nem csinál semmit, de hibaüzenet sincs" biztos? Hogyan kéred le a hibaüzeneteket?
    Egyébként meg ennek a szintaktikának:

    $sql="INSERT INTO stats (ip, user, downloads) VALUES (:userip, :user, 1)
    ON DUPLICATE KEY UPDATE downloads = downloads + 1";

    tulajdonképpen nem sok értelmét látom (még ha egyébként helyes is!), amikor a következő:

    UPDATE stats SET downloads = downloads+1
    WHERE ip=:userip AND user=:user;

    szerintem sokkal beszédesebb.

    Itt a query-ben direkt használtam a prepared statementes szintaktikát, a másik belinkelt hsz.-emben láthatsz példát rá, hogyan kéne átírni ezt a kódodat, hogy ne legyen összefűzött a query (mivel lehet, hogy nem megbízható adat, ha pl. query stringből érkezik, mindig érdemes a legrosszabbra számítani).
    Hogy hogyan ellenőrzöd, hogy sikeres volt-e a query, vagy pedig történt valami hiba, azt is meg kellene mutatnod.

    =========================

    (#14966) PumpkinSeed :
    nincs mit.

  • #11612 Sk8erPeter nagyúr pakriksz #11611
    Új Válasz #11612
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Sk8erPeter

    nagyúr

    válasz pakriksz #11611 üzenetére

    Ezeket a népszerűbb CMS-ek (Drupal, WordPress, ...) mind tudják.

  • #10870 modder aktív tag pakriksz #10859
    Új Válasz #10870
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    modder

    aktív tag

    válasz pakriksz #10859 üzenetére

    azt hiszem pl. dotcloud mysql adatbázisához hozzá tudsz férni kívülrűl.
    Egyébként szerintem nem olyan bonyolult összehozni egy ilyet, amiről beszélsz. egy szimpla REST apival megoldható, pl json-ben adná vissza a sorokat. szerintem még egy több megás result setet is simán vissza lehet adni egyben, miért is ne.

    Ha nem szimpi egyben visszaadni, akkor szerver oldalon csinálhatsz olyat, hogy a query-d végére fűzöl (a távoli kliens számára transzparens módon) OFFSET x LIMIT y -t, session változóban eltárolod a query-t egy egy referenciával és egy iterációt számláló változóval.
    Miután a kliens elküldte a query-t, visszakapja a referencia számot, és erre hivatkozva csak next-next-next-eket küld a proxynak.
    A proxy a referencia szám alapján kikeresi a query-t, növeli az iterációs változó értékét, majd ez alapján az érték alapján új offsetet ad az előzőleg letárolt query-nek. Az új offsettel lefuttatja a query-t, majd elküldi a választ.
    A kliens a referencia számra hivatkozva a next-next-next... kérésekben visszakapja pl json-ban a választ.

    Ami itt rettentő fontos, hogy mivel plain SQL lekérdezéseket küldesz a proxynak, legalább a requestet kezdeményező klienst autentikálni kell valahogy. Pl egy egyszerű szimmetrikus kulcsú HMAC algoritmussal aláírni az elküldött SQL query-ket, majd a proxy oldalon ellenőrizni, hogy tényleg a megfelelő kulccsal lett-e aláírva a query. ha igen, akkor futhat, ha nem, akkor hitelesítetlen felhasználó próbálja meg elérni a proxy-t

  • #10860 biker nagyúr pakriksz #10859
    Új Válasz #10860
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    biker

    nagyúr

    válasz pakriksz #10859 üzenetére

    minden további nélkül, csak kicsit gondolkozz...
    változó átadás.... :)

Új hozzászólás Aktív témák

Hirdetés