MySQL boolean + text

Megjelenített sorok: 0 - 5 ( 6 összesen, a lekérdezés 0.0008 másodpercig tartott)
SELECT *
FROM user
WHERE email = FALSE

Ahol email TEXT típusú.

Ugyanígy:

Megjelenített sorok: 0 - 5 ( 6 összesen, a lekérdezés 0.0008 másodpercig tartott)
SELECT *
FROM user
WHERE email = 0

Következésképpen ha POST helyett GET-tel nézem a címet, amikor a POST üres (NULL, majd ebből 0), ami hamis érték, akkor a lekérdezés minden sort visszaad a user táblából.

Az ilyen implicit konverzió mire jó? A TEXT értéke nem kéne hogy egyenlő legyen egy BOOLEAN-nal, főleg egy FALSE értékkel. Még ha azt mondjuk hogy a nem üres TEXT legyen TRUE, az elfogadható lehet. De amúgy inkább a FALSE-t konvertálja 0-vá, valamint a 0-t szöveggé, ne fordítva...

Kicsit meg vagyok illetődve.

( hrgy84 | 2012. 02. 05., v – 18:11 )

A NULL sosem konvertalodik, ennyire ne szaladj elore. Valamint, tessek olyan keretrendszert hasznalni, ami az ures mezoket nem nullara, falsra, meg egyebekre konvertalja, hanem NULL-ra. A tobbit tessek kidobni az ablakon.

Egyebkent nem irtad, de tippre olyan itemeket kaptal, ahol ures az email, tehat nem feltetlen null, hanem akar ures string.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

CodeIgniter Input Class, "The function returns FALSE (boolean) if the item you are attempting to retrieve does not exist", ebben igazad van.

Az email sehol nem null, nem üres, minden sort visszakapsz ezzel a lekérdezéssel. A query pontosan úgy hangzik string-ként, hogy select * from user where email=0, tehát a false-ból később 0 lett, de ez már lényegtelen, ugyanúgy működnek.

A CodeIgniternek nem ez az első hülyesége, de ez esetben a MySQL is fura nekem.

A CI-ben ez kivételesen nem hülyeség - hiszen nem mindegy, hogy ha létrehozol egy form-ot és létrehozol egy email nevű, opcionális mezőt, valamint a get/post inputot $this->input->get/post("emil") (elírt email!) módon kéred le, akkor csak nehezen fogsz rájönni, hogy miért nem ad meg senki se email-t :)

Ezzel megint visszajutottunk a "tessék kidobni az ablakon" részhez. Vagy lehet unit testet összekókányolni CI-hez...

Az a vicc, hogy például Grails-ben a fw része a unit test, de ott meg a GORM osztályokhoz automagically hozzátevődik egy pár metódus bootstrap közben, amiket nem lehet unit testelni, mert a mock-olt domainek nem támogatják. Integration testelni elvileg lehetne az éles adatbázissal, stb., de az meg a múltkor arra is igazat mondott hogy üres az adatbázis, meg arra is hogy benne van az a rekord, amit amit két sorral korábban töröltem, szóval az meg bugosnak tűnik.

( zeller | 2012. 02. 06., h – 09:47 )

Jelen esetben a böngészőtől kapott adat NEM változtat a szerver oldal állapotán, tehát szemantikailag GET-et kéne használni.
Az üres mezőt meg igenis NULL-ként kéne továbbadnia a keretrendszernek az SQL felé. Ha nem így tesz, akkor sz@r, mert az üres mező nem "0", nem " ", nem "", hanem ÜRES.

"Jelen esetben a böngészőtől kapott adat NEM változtat a szerver oldal állapotán, tehát szemantikailag GET-et kéne használni."

Honnan tudod? Ez csak egy példa volt :) A lényeg az, hogy ha paraméter nélkül érem el azt, amit paraméterrel gondoltam volna elérni, az összes WHERE=paraméter igazra fog kiértékelődni minden sorra.

És ez csak részben a keretrendszer hibája, szerintem "email@gmail.com" == false nem kéne hogy igaz legyen, és "email@gmail.com" == 0 sem kéne hogy igaz legyen. Nekem ez sehogy nem áll így össze.

A példa szerint select-ben használod,a mi nem változtatja meg a szerver állapotát. Ha insert/update/delete is van, azaz kétszer elküldve az adatokat más lesz a szerver válasza, akkor post. Egyébként az email is null or email = "" randa körbegányolása a dolognak, bár én onsubmit eseményre azért megnézném, hogy az email mező valami kukac valami egy vagy több pont-valami formátumú-e?