🚀 go-pugleaf

ddd <ddd@niematakiegoemaila.pl> wrote:

> cur.execute("SELECT * FROM %%s", ("routers",))
                             ^^^
                        tylko jeden znak %

Jeśli nie używasz operatora %, to znak '%' w łańuchu nie
zyskuje specjalnego znaczenia. Zobacz sobie co się wyświetli:

wzorzec = 'test=%s'
print wzorzec		# => 'test=%s'
print wzorzec % 'test'	# => 'test=test'

w.

Po zmianie na pojedyńczy znak wywala błąd w składni SQL. Co tam może być 
źle? Tym bardziej, że polecenie:

cur.execute("SELECT * FROM routers")

wykonuje się bez problemów tymczasem po wywaleniu tego jednego procenta 
linijka:

cur.execute("SELECT * FROM %s", ("routers",))

wywala błąd:

_mysql_exceptions.ProgrammingError: (1064, "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 ''routers'' at line 1")

Z tego co sprawdziłem błąd mysql 1064 oznacza złe użycie słów 
kluczowych. I dalej nie za bardzo potrafię to przypiąć do czegoś.

W dniu 15.12.2009 13:22, Wojciech Muła pisze:
> ddd<ddd@niematakiegoemaila.pl>  wrote:
>
>> cur.execute("SELECT * FROM %%s", ("routers",))
>                               ^^^
>                          tylko jeden znak %
>
> Jeśli nie używasz operatora %, to znak '%' w łańuchu nie
> zyskuje specjalnego znaczenia. Zobacz sobie co się wyświetli:
>
> wzorzec = 'test=%s'
> print wzorzec		# =>  'test=%s'
> print wzorzec % 'test'	# =>  'test=test'
>
> w.

OK działa tylko jak dam:

cur.execute("SELECT * FROM %s" % "routers")

Ale powinno także działać w wariancie z dwoma argumentami z czego drugi 
powinien być tuplą. Dla innych paramstyle'ów próbowałem i był podobny 
skutek. Czyżbym źle używał funkcji execute? Czyżbym źle rozumiał 
filozofię stosowania oddzielnie zapytania i oddzielnie argumentów zapytania?

W dniu 15.12.2009 13:22, Wojciech Muła pisze:
> ddd<ddd@niematakiegoemaila.pl>  wrote:
>
>> cur.execute("SELECT * FROM %%s", ("routers",))
>                               ^^^
>                          tylko jeden znak %
>
> Jeśli nie używasz operatora %, to znak '%' w łańuchu nie
> zyskuje specjalnego znaczenia. Zobacz sobie co się wyświetli:
>
> wzorzec = 'test=%s'
> print wzorzec		# =>  'test=%s'
> print wzorzec % 'test'	# =>  'test=test'
>
> w.
Widzę swój głupi błąd. Zmiennej paramstyle nie można zmieniać. A ja 
ciągle próbowałem aplikować zły styl wpisywania zmiennych do zapytania.
Po prostu zawsze muszę stosować format

cur.execute("SELECT * FROM %s" % (tupla_argumentów))

Wstyd mi za siebie :)

ddd:
> cur.execute("SELECT * FROM %s" % "routers")
> 
> Ale powinno także działać w wariancie z dwoma argumentami z czego drugi
> powinien być tuplą. Dla innych paramstyle'ów próbowałem i był podobny
> skutek. Czyżbym źle używał funkcji execute? Czyżbym źle rozumiał
> filozofię stosowania oddzielnie zapytania i oddzielnie argumentów
> zapytania?

W przypadku cur.execute("SELECT * FROM %s", ("routers",)) próbujesz 
przemycić nazwę obiektu jako parametr zapytania (napis), co daje efekt jak
mysql> SELECT * FROM "routers"; -- ERROR 1064
zamiast 
mysql> SELECT * FROM routers; -- OK

.pk.

Użytkownik "ddd" <ddd@niematakiegoemaila.pl> napisał w wiadomości 
news:hg80fq$kku$1@achot.icm.edu.pl...
>
> skutek. Czyżbym źle używał funkcji execute? Czyżbym źle rozumiał filozofię 
> stosowania oddzielnie zapytania i oddzielnie argumentów zapytania?

IMHO tak :). W Oracle PLSQL też mi nie zadziała:

SELECT * FROM :table_name

a zadziała

SELECT * FORM tabele WHERE kolumna = :value

Co jest o tyle logiczne, że zmienne wiązane to nie tylko "elegancja" i 
zabezpieczenie przed SQL injection, ale również optymalizacja zapytania po 
stronie silnika bazy danych. Wynik polecenia ze nieokreśloną nazwą kolumny 
lub tabeli nie nadaje się do cache. Ze zmiennymi w klauzuli WHERE - tak. 

W dniu 15.12.2009 14:04, William Bonawentura pisze:

> IMHO tak :). W Oracle PLSQL też mi nie zadziała:
>
> SELECT * FROM :table_name
>
> a zadziała
>
> SELECT * FORM tabele WHERE kolumna = :value
>
> Co jest o tyle logiczne, że zmienne wiązane to nie tylko "elegancja" i
> zabezpieczenie przed SQL injection, ale również optymalizacja zapytania
> po stronie silnika bazy danych. Wynik polecenia ze nieokreśloną nazwą
> kolumny lub tabeli nie nadaje się do cache. Ze zmiennymi w klauzuli
> WHERE - tak.

Teraz pojąłem całkowicie ten mechanizm. Po prostu czytając dokumentację 
MySQLdb stoi jak byk:

Parameter placeholders can only be used to insert column values. They 
can not be used for other parts of SQL, such as table names, statements, 
etc.

Więc gdy się chce odnosić do czegoś innego niż do wartości kolumn to 
muszę to robić przez proste pythonowe podstawienie zmiennej do stringa a 
nie przez funkcję dwuparametrową execute()

Użytkownik "ddd" <ddd@niematakiegoemaila.pl> napisał w wiadomości 
news:hg82kl$mfu$1@achot.icm.edu.pl...
>
> Teraz pojąłem całkowicie ten mechanizm. Po prostu czytając dokumentację 
> MySQLdb stoi jak byk:
>
> Parameter placeholders can only be used to insert column values. They can 
> not be used for other parts of SQL, such as table names, statements, etc.
>
> Więc gdy się chce odnosić do czegoś innego niż do wartości kolumn to muszę 
> to robić przez proste pythonowe podstawienie zmiennej do stringa a nie 
> przez funkcję dwuparametrową execute()

Tak jest. I co więcej, te parametry przekazane do execute, nie są wiązane z 
SQLem ani przez bibliotekę Pythona ani przez klienta bazy danych tylko 
gdzięś po drugiej stronie przez sam motor bazy.