[lutecki]

$dupa->a->b = 'abcd';

echo $dupa->a->b; // wyświetla abcd

$server0 = $pdo->exec("
 INSERT INTO
 aso_statuses
 SET
 statuses_date = NOW(),
 statuses_content_addition = '$dupa->a->b',
"); // Nie wykonuje, bo $dupa->a->b jest puste

Dlaczego dane z "głębokiego obiektu" w #php działają przy echo, a do #mysql dane nie wchodzą?

#programowanie

[zakopiak]

@lutecki:
Bo:

echo $dupa->a->b

to co innego

[MrDracek]

@lutecki: bo z wypowiedzi @zakopiak - nie wiadomo, kiedy coś jeszcze jest zmienną, a co już jest częścią stringa.

Prostym, ale kującym w oczy sposobem jest dodanie zmiennej w stringu w klamerki:

statusescontentaddition

[zakopiak]

@MrDracek: A jeszcze lepszym byłoby bindowanie parametrów zamiast składać SQLa ze stringów :P

[LuckyLuke_2776]

@lutecki: @MrDracek: a jeszcze lepszym bindowanie zmiennych

[MrDracek]

@zakopiak: chciałem zmienić nieco tekst, ale wykop nie pozwolił mi już na edytowanie.

[lutecki]

O to właśnie chodziło, dzięki! Coś mi świtało z tymi klamrami

[MrDracek]

@LuckyLuke_2776 i @zakopiak: niech się chłopak najpierw podstaw nauczy xd

[Jake_921]

@lutecki: Nie wykonuje się nie dlatego, że $dupa->a->b jest puste, tylko dlatego, że używasz złej składni. Nie można tak wrzucać pól czy funkcji obiektów do stringa. Masz dwie opcje:

$string = "blabla{$dupa->a->b}blabla";

Albo

$string =

[Jurigag]

@MrDracek: bindowanie zmiennych i nie pisanie kodu który jest podatny na sql injection to jest podstawa, dobrych praktyk trzeba się uczyć od samego początku i je trzeba promować, bo potem pojawi się na produkcji kod z dziurami np

[MrDracek]

@Jurigag: dobrą praktyką byłoby unikanie korzystania bezpośrednio z PDO, a dane powinny być już dawno oczyszczone w innej warstwie.

[Jurigag]

@MrDracek: niby czemu unikanie korzystania z pdo to dobra praktyka ? xd bardzo dziwny argument, przecież to podstawowe narzędzie do komunikacji z bazami danych w PHP

[MrDracek]

@Jurigag: czytelność, uniknięcie całkowitej zależności i możliwość podmiany na cokolwiek innego.

[Jurigag]

@MrDracek: no to przecież interfejs sobie może dodać ale jego implementacja i tak o pdo się musi opierać np

[Jurigag]

@MrDracek: a czekaj, my chyba kiedyś mieliśmy podobną dyskusję że to najchętniej byś stosował ORM do wszystkiego xD również chyba do prostych selectów xd

[MrDracek]

@Jurigag: nie. To nie ze mną prowadziłeś takie dyskusje. Ale widać w takim razie że więcej osób ma odmienne zdanie niż Twoje.

[Jurigag]

@MrDracek: ależ to że ludzie są w błędzie to nie ma problemu, mogą być :)

[LuckyLuke_2776]

@MrDracek: @Jurigag: też uważam, że "unikanie korzystania bezpośrednio z PDO" to #!$%@? (✌ ﾟ ∀ ﾟ)☞

[MrDracek]

@Jurigag: ogólnie nawet prosta sugestia o zrezygnowanie z exec bezpośrednio przez PDO to dobrze pokazuje: jak mam już 100 różnych zapytań bezpośrednio w PDO i mam teraz zmienić 80% z nich żeby uniknąć mysql injection - to już jest dług technologiczny dla nawet prostego kodu.

[Jurigag]

@MrDracek: ale przecież tutaj chociażby DQL nie rozwiązuje tego problemu w żaden sposób, nadal trzeba korzystać z binding parametrów także o co ci chodzi?