- saxus blogja
- A hozzászóláshoz be kell jelentkezni
- 2081 megtekintés
Hozzászólások
na nemazé, hogy védjem, de:
mysql> create table blabla (
-> bla int not null
-> );
Query OK, 0 rows affected (0.09 sec)
mysql>
mysql> insert into blabla values (1);
Query OK, 1 row affected (0.09 sec)
mysql>
mysql> update blabla set bla = null;
Query OK, 1 row affected, 1 warning (0.10 sec)
Rows matched: 1 Changed: 1 Warnings: 1
mysql> show warnings;
+---------+------+-----------------------------+
| Level | Code | Message |
+---------+------+-----------------------------+
| Warning | 1048 | Column 'bla' cannot be null |
+---------+------+-----------------------------+
1 row in set (0.00 sec)
mysql> select * from blabla;
+-----+
| bla |
+-----+
| 0 |
+-----+
1 row in set (0.00 sec)
mysql Ver 14.14 Distrib 5.5.24, for Linux (i686) using readline 5.1
- A hozzászóláshoz be kell jelentkezni
Nem azért, hogy támadjam, de ...
mysql> select * from blabla;
+-----+
| bla |
+-----+
| 0 |
+-----+
1 row in set (0.00 sec)
...ez védhetetlen. Warning ide vagy oda.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
agree.
- A hozzászóláshoz be kell jelentkezni
Óbzmg... +1
- A hozzászóláshoz be kell jelentkezni
miert nem ellenorzod az inputot? :-)
- A hozzászóláshoz be kell jelentkezni
Te is aztán megfogtad a lényeget. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
az ironia detektort is set null-LOLtad? :-)
- A hozzászóláshoz be kell jelentkezni
saxus is írt egy :-)-t a végére.
- A hozzászóláshoz be kell jelentkezni
Azért a postgresql sem tökéletes, mi a db-szintű enumokkal szívtunk, az lett a vége hogy kivágtuk és a check constraint lett belőle (textual típus). Csak egy apró hint: 9.1 előtt 6 lépésből áll egy létező enumhoz opció hozzáadása, amennyiben egy egy oszlop már használja típusnak (ismétlendő 3 lépés minden tovbábbi oszlopnál), 9.1 -ben már van add option szerűség, de tranzakcióban nem használható, eldobni viszont lehet! (érted: egy opció hozzáadás kevésbé erős művelet mint az enum eldobása, mégis csak az utóbbit engedélyezik tranzakcióban).
A DB migrációs eszközök, mint a liquibase persze tranzakcióban futnak (és egyébként is, ne hakkoljunk).
Mindegy, ne DB-flameljünk :)
- A hozzászóláshoz be kell jelentkezni
Ismerem a szívásokat a pg+enummal.
Ami nekem viszont helyből fura, hogy miért engedi eldobni, főleg tranzakción belül. Az ALTER az DDL és tudtommal a PostgreSQL nem enged semmilyen DDL utasítást tranzakción belül csak DML-t.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Rosszul tudod, nagyon is sokmindent meg lehet tenni tranzakcióban:
http://stackoverflow.com/questions/1108749/limits-on-postgresql-schema-…
- A hozzászóláshoz be kell jelentkezni
Na ez nekem új. No mindegy, ma is tanultam valamit.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Asszem ha van defaultja a columnnak, akkor az lesz berakva a 0/null helyett. Mondjuk ezzel egyutt gyasz.
Update: hmm... vagy ez csak az inzertre vonatkozik?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Csak az insertre (és az úgy is van jól, azért van). Viszont jelen esetben nincs default értéke a mezőnek.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
mysql> create table blabla (
-> bla int not null
-> );
Query OK, 0 rows affected (0.17 sec)
mysql> insert into blabla values (1);
Query OK, 1 row affected (0.12 sec)
mysql> update blabla set bla = null;
ERROR 1048 (23000): Column 'bla' cannot be null
A trukk:
mysql> SET sql_mode = 'TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)
- A hozzászóláshoz be kell jelentkezni
Es ez mer' nem difolt?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
És miért van ettől eltérő?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Unortodox felfogásban dolgozik, na... :-D
- A hozzászóláshoz be kell jelentkezni
Igen, időközben mondták már mások is, hogy a MySQL-nek vannak ilyenjei. (Rég volt utoljára, na.)
Viszont könyörgöm, kinek jó ez? Azért, mert néhány balfasz nem tud normálisan kódolni?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Szerintem regen a mysql ilyen idetlen modon mukodott, aztan meg kellett orizni visszafele a kompatibilitast.
- A hozzászóláshoz be kell jelentkezni
Ne mondd, hogy idestova tobb mint husz verzio nem volt eleg, hogy deprecaljak. Bezzeg a PHP akar naponta tud API-t valtoztatni... Szanalmas valahol. Akkor is, ha a MySQL tovabbra is a kedvenc DB szerverem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Mielott nagy mellennyel kijelentunk ilyeneket, erdemes azert vegig gondolni. Tegyuk fel, hogy tenyleg valamikor a mysql igy kezelte a null-os oszlopokat. A mysqlt hasznalo fejlesztok erre a viselkedesre szamitottak, amikor programokat irtak. Jottek az ujabb verziok, a visszafele kompatibilitast meg kellett orizni, elvegre nagy blama lett volna, ha hirtelen sok-sok program nem mukodott volna, mert megvaltozott a mysql viselkedese. Raadasul nekem az a gyanum, hogy a mai napig keszulnek olyan kodok, amik ezt a viselkedest feltetelezik. Az, hogy a mysql ezt a viselkedest allithatova tette, egy nagyon jo megoldas, mert igy a regi programok tudnak mukodni, de aki mar az ertelmesebb, szigorubb viselkedest akarja, az konnyeden at tudja allitani.
Hasonlo jelenseg mashol is fellelheto. Pl. javaban van 1-2 deprecated osztaly es fuggveny, de a mai napig nem irtottak ki (es talan sohase fogjak). Masik kivalo pelda az x86 architektura. A mai napig valos modban indul el (mintha csak egy XT lenne).
- A hozzászóláshoz be kell jelentkezni
Ember! A NULL nem azonos a 0-val, márpedig itt NULL -> 0 konverzió történik ami sehol, soha nem védhető. Ha valaki nem tanulta meg, hogy a 0, mint szám, a nulla hosszúságú string és a NULL érték az HÁROM, különböző, nem keverhető dolog az SQL-ben, az fogjon egy kapát, és menjen kapálni.
Egyébként meg ha egy constraint-et megsért egy művelet, az mi a lópikuláért van hatással az érintett adatra?! Ilyen alapon egy uniq esetében is mondhatná, hogy warning, már van ilyen, és bebacarinthatna egy nullát (akár sokadikként is) a táblába, aztán az ember néz ki a fejéből, hogy mi van.
- A hozzászóláshoz be kell jelentkezni
Félreérted, nem az a probléma, hogy megőrizték a visszafelé kompatibilitást (egyébként ez dícsérendő). A probléma azzal van, hogy ezt valaha így implementálták. Értem én, hogy a MySQL-nél sok mindenben tettek a szabványra nagy ívben és úgy vagy azt implementálták, ami gyors/gyors tud lenni, csak ugye most látjuk az eredményét. Különféle módok, figyeljen még erre is az ember stb. stb. stb.
Arról nem is beszélve, hogy amit csinál, SQL szabványt tekintve legalább annyira hülyeség, mint PHP-ben a 0 == "" (true), 0 == null (true), "" == null (false).
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Különféle módok, figyeljen még erre is az ember stb. stb. stb.
fentebb rohogtel rajta, hogy validald az inputot, mert ha ez valoban gagyi is, de attol meg a te sarad, hogy egy set null egyaltalan az sql szerver ele kerulhet...
- A hozzászóláshoz be kell jelentkezni
Miért is hihetetlen, hogy egy adatforrás hiányos adatokat küld, és az eljut az insert/update -ig? Jó, legyen, az inputot IS validálni kell, de egy RDBMS ne csináljon már NULL-ból 0-t, vagy üres stringet, vagy akármi mást...
- A hozzászóláshoz be kell jelentkezni
Szerintem te nagyon rosszul értelmezed az adatbázis kezelők [és a különféle constraintek] kapcsolatát: az adatbázis-kezelő dolga, hogy fenntartsa az adatbázis konzisztenciáját, nem az enyém, hogy fejben tartsam egy random elém kerülő DB struktúráját.
Nem csak alkalmazásból lehet SQL utasítást kiadni, hanem kézzel is. Az input jelen esetben a mysql konzolon jött létre.
Szerk: Na jó, nagyon kajakóma van (még mindig) és úgy is rég volt hup certificated autós hasonlat:
Hh kiszedhetetlen iBenzinTankPro van a kocsiban es te arra utasitod a szerelot, hogy szedje ki, akkor ne ures tankot rakjon mar bele. ( :) )
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Szerintem te nagyon rosszul értelmezed az adatbázis kezelők [és a különféle constraintek] kapcsolatát
jaj, dehogy. Csak a lamasagot probaljuk meg elosztani kozted es a mysqld kozott... :-)
- A hozzászóláshoz be kell jelentkezni
Nincs mit elosztani, itt a mysql a hülye. Normális RDBMS-ben a NULL a 0 és a "" teljesen mást jelent. Ha NULL-t akarok beszúrni valahova, ahova explicite TILOS, akkor ne konvertálja már át önhatalmúlag, ugyanis így nem az kerül a DB-be, ami elindult befelé, hanem valami egészen más; a constraint tegye a dolgát, és akadályozza meg a hibás adatnak a db-be kerülését, és hasaljon el rajta az insert/update.
- A hozzászóláshoz be kell jelentkezni
Azert kulonbseg van a Java-beli osztalyok, es egy definialhatoan HIBAS mukodes kozott. Ez egy BUG, akarki akarmit is mondjon, az SQL szabvanyok eleg durva megsertese. Jo, igen, valaki regen igy implementalta. Bar mar ez is hulyeseg volt, a multon nem lehet valtoztatni. De konyorgom, jo eselye van annak, hogy ez egy MySQL 3-as kod, azota volt 2 fo- es kurvasok alverziovaltas (de meg ha MySQL 5-os kod is, akkor is minimum 60 alverziovaltason vagyunk tul). Nem tudom elkepzelni, hogy ma, az internet koraban, ahol egy fejleszto nem tud ket sort irni neked a google es ugy egyebkent az internet hasznalata nelkul - szoval az internet koraban ne lehetne ot alverzion belul kiszedni az ilyen oruleteket. Nem olyan nehez am, csak kommunikalni kellene.
Ha valaki egy bugra epitette a programjat, az kerlekszepen szopjon. Semmilyen szabvany szerint nem ertelmezheto mukodes az, amit a MySQL csinal.
Azt mar csak halkan teszem hozza, hogy ha meg akartak orizni a kompatibilitast, am tegyek. De ezt a hibas mukodest, mint default mukodest hozni... Mert ha valami konfig opcio/extra SET utasitas moge van rakva, a kutyat nem erdekli.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Ha valaki egy bugra epitette a programjat, az kerlekszepen szopjon.
Ezzel feltetelezed hogy szandekosan tett igy, holott siman lehet side-effect is.
- A hozzászóláshoz be kell jelentkezni
Es ez min is valtoztat? Ha kijon a dolog, mint hiba, akkor ki kell javitani, pont. Akar bugra epitett, akar side effect volt. Irrelevans.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Tök mindegy, el van ...va, mert a constraint nem arról szól, hogy konvertáljon valamit valami mássá, hanem arról, hogy adott érték NEM kerülhet be a táblába. Mit szólnál hozzá, ha egy int mezőbe beszúrni kívánt 'A' esetén egy warning után beírná a mezőbe, hogy 65? Vagy nem is 65, hanem 1, mert az ABC első betűje? Vagy 42, mert csak?! Most a NULL esetén ilyet csinál, tetézve azzal, hogy a NULL a 0 és az '' értékek nem azonosak, tehát a konverzió logikailag HIBÁS. A NULL ugyanis azt jelenti, hogy nincs értéke az adott mezőnek, a 0 meg azt, hogy az értéke nulla.
Aki ezt a különbséget nem képes felfogni, az DB-hákolás helyett kapáljon inkább.
- A hozzászóláshoz be kell jelentkezni
Igen, azert, mert nehany balfasz nem tud normalisan kodolni. A magic_quotes is epp amiatt volt, hogy rohadnanak meg mind. (mondjuk van ra include-olhato scriptem, ami kikapcsolja, visszacsinalja, hogy utana normalisan lehessen kezelni)
--
a publikus az egy JOGI fogalom abban az értelmezésben ahogy mi használtuk! nem műszaki. - RockWood1911
- A hozzászóláshoz be kell jelentkezni
Én úgy döntöttem, hogy nem akarok többé MySQL-t látni, amikor egy minor verzióban egy ilyen változtatás miatt sikerült jópár korrupt táblát gyártanunk:
D.1.97. Changes in MySQL 5.0.2 (01 December 2004)
Incompatible Change: The precedence of NOT operator has changed so that expressions such as NOT a BETWEEN b AND c are parsed correctly as NOT (a BETWEEN b AND c) rather than as (NOT a) BETWEEN b AND c. The pre-5.0 higher-precedence behavior can be obtained by enabling the new HIGH_NOT_PRECEDENCE SQL mode.
- A hozzászóláshoz be kell jelentkezni
:)))
- A hozzászóláshoz be kell jelentkezni