Nie do końca rozumiem jak parametryzacja zapobiega takim sytuacjom: https://xkcd.com/327/
Czy jeśli wstawimy pana Drop TABLE do pstmt.setString(1, nazwa); to nie wyjdzie na to samo?
0
0
A nie ma jakiejś walidacji parametrów pod spodem?
2
To nie jest pytanie z Javy, ale z SQLa i zależy od bazy danych i tego, jak procesowane są zapytania. Każdy SQL przed wykonaniem musi być skompilowany. W większości silników może zostać skompilowany do Query lub ParametrizedQuery.
Przykładowo dla Oracle'a jeśli chcesz znaleźć studenta o imieniu "SOME STRING" to możesz to zapisać na dwa sposoby:
SELECT * FROM STUDENT WHERE FIRST_NAME = 'SOME STRING';
-- lub
SELECT * FROM STUDENT WHERE FIRST_NAME = :some_name;
-- a potem za :some_name podstawić 'SOME STRING'
Różnica w pierwszym przypadku jest taka, że Oracle kompiluje całe zapytanie z warunkiem FIRST_NAME = 'SOME STRING' włącznie.
W drugim przypadku skompilowane zapytanie zawiera parametry, tzn. wszystkie parametry które podasz już nie zostaną skompilowane - jedynie podstawione w odpowiednie miejsce.
1
RAwtC napisał(a):
Nie do końca rozumiem jak parametryzacja zapobiega takim sytuacjom: https://xkcd.com/327/
Czy jeśli wstawimy pana Drop TABLE do pstmt.setString(1, nazwa); to nie wyjdzie na to samo?
Nie wyjdzie. bo PreparedStatement nie jest potem klejony do pojedynczego Stringa. PreparedStatement leci prosto do sterownika do bazki, który to dokładnie określa bazce co jest parametrem, a co składnią zapytania. Dodatkowym plusem PreparedStatement jest to, że bazka może sobie keszować plan wykonania (execution plan), bo przy każdym wywołaniu pstmt leci dokładnie takie samo zapytanie, np "SELECT * FROM users WHERE name = ?".