Version imprimable
Bon ok j'avais zapé le DISTINCT :aie: donc on oublie l'histoire des doublons.
Sinon ça ne veut pas dire qu'il n' y a pas de NULL :)
Mais je vais arrêter d'être chiant :mouarf:, donc oriente toi vers des recherches de bug concernant ta version. En cherchant méga vite fait j'ai trouvé çà :
http://forums.mysql.com/read.php?121,143298,143298
STP tiens nous au courant, ça peut en intéresser plus d'un.
Salut
Bon pour te débarasser de la petite bete qui te trotte en tete je peux t'assurer qu'il n'y a pas de NULL car je ne permet pas de NULL sur AddrID dans ces tables !
Je viens d'upgrader en 5.1
Meme problème
Petite info je suis en MyIsam et pas InnoDB
Pour celui qui veut essayer, je fais deux petite tables, une avec 2256 records l'autre avec 117
Et chacun peut essayer dans son environnement !
On verra bien si c'est
- structurel
- ou un bug de version(s)
- ou lié a l'environnement !
je n'aurai pas le temps ce soir, mais je suis preneur !Citation:
Envoyé par olibara
Merci, St thomas est satisfait :)Citation:
Envoyé par olibara
Et +1 pour le jeu de test.
Ouf !
J'ai ramé une bonne partie de la journée a refaire fonctionner Navicat qui plantait apres l'upgrade MySql 5.1
Il m'aura couté cher ce Not In :aie::aie:
Voici donc deux tables permettant de facilement reproduire l'effet null du not in
Et le query qui va avec
Code:
2
3
4
5
Merci pour les tables de test !
Pour l'anecdote, il y a bien un NULL sur la première ligne de okx, où addrid n'est pas en NOT NULL.
Sur le fond, il semble bien que tu mettes en évidence un bug du NOT IN, qui persiste encore dans la version 5.1.19.
Caramba ! :oops:
Tu a raison j'ai laissé les ALLOW NULL dans la table OK, et je n'avais pas vu ce NULL
Sans lui ca marche bien
Donc le bug vient bien de ce null
Je dirais meme 5.1.28 !!Citation:
Sur le fond, il semble bien que tu mettes en évidence un bug du NOT IN, qui persiste encore dans la version 5.1.19
Effectivement. Bravo pour avoir trouvé le contournement, je n'avais même pas pensé à tester sans le NULL :aie:Citation:
Envoyé par olibara
Tu es mûr pour devenir crashtesteur chez MySQL AB :king:
c'est :resolu: pour toi ?
Mmmouais !
Résolu en esperant que les Crashmakers de Mysql AB liront un jour ce post :mrgreen:
En fait dans le cas présent le NULL agit comme un Joker !
C'est la valeur magique qui represente TOUT
J'en connais qui parviendront a debattre une logique sur le sujet :mrgreen::mouarf::bug:
Il ne tient qu'à toi d'aller poster le truc sur bugs.mysql.com.Citation:
Envoyé par olibara
'farpaitement ! j'étais justement en train de vérifier les tables de vérité dans mon Celko (Data and database concepts in practice, que je recommande à tous) :chin:Citation:
Envoyé par olibara
Donc, en termes de logique tri-valuée (TRUE / FALSE / UNKNOWN), Valeur IN (NULL) est UNKNOWN, et donc Valeur NOT IN (NULL) devrait être UNKNOWN aussi. Le bug semble indiquer que, dans ce cas, MySQL interprète (à tort) le Valeur NOT IN (NULL) comme TRUE et non UNKNOWN.
Je t'avais dis que certains parviendront a prétendre que c'est logique !! :(
http://bugs.mysql.com/bug.php?id=40035
http://bugs.mysql.com/bug.php?id=40035
Non, le gars se plaint que le résultat est NULL (donc UNKNOWN), alors que c'est logique que ce soit NULL. Ton bug est que ce n'est pas NULL mais TRUE.Citation:
Envoyé par olibara
Salut
Bon le gars c'est moi !
J'ai probablement mal exprimé la chose
TableA contient 2000 ID
TableB contient 100 ID
Quand je fais
Je recoit 1900 ID : normalCode:
2
3
4
5
Si j'ajoute un ID NULL dans table B et que je fais le meme select, le résultat et NULL : pas de row : NADA : 0 records : rien du tout
Je sais pas comment le dire pour qu'on me comprenne
:rire:Citation:
Envoyé par olibara
Enchanté !
Non, en fait c'est lui qui a raison et moi qui déconne :aie: :aie: :aie:Citation:
Envoyé par olibara
J'ai bon jusque-là...Citation:
Envoyé par Antoun
Là par contre, je m'emmêle les pinceaux. Que tu obtiennes un résultat vide indique que le NOT IN n'est pas TRUE (en l'occurrence, qu'il est UNKNOWN).Citation:
Envoyé par Antoun
Dit plus simplement :
Je peux aussi te le dire comme ça :Citation:
Envoyé par olibara
Le NULL représente l'inconnu. Quand tu demandes "sors-moi les ID qui sont dans NULL", un SGBD te réponds "je n'en sais rien". Quand tu demandes "sors-moi les ID qui ne sont pas dans NULL", il te répond aussi "je n'en sais rien".
Pour plus de détails sur les points vicieux du NULL, cf http://sqlpro.developpez.com/cours/null/. Je vais lui suggérer d'ajouter un paragraphe "NULL et IN" !
Bon j'arrive un peu tard mais j'ai pas trop su exploiter immédiatement les fichiers :aie:.
Juste pour compléter un peu, le comportement de IN et NOT IN n'est pas tout à fait identique fasse au NULL.
IN(NULL) et NOT IN(NULL) ne renvoient rien et c'est normal.
IN(1,NULL,2) marche bien, si ce n'est que les données NULL ne sont pas renvoyées, mais c'est normal.
Par contre NOT IN(1,NULL,2) ne renvoie toujours rien, ce qui peut surprendre mais comme les SGBDs se comportent tous de la même manière ça ne peut donc pas être considéré comme un bug.
Ma question serait plutôt pourquoi IN(1,NULL,2) renvoie 1 et 2, le SGBD pourrait considérer que la présence d'inconnu dans la clause l'empêche de résoudre la requête.
Mais mes connaissances en logique sont plus que limitées... le Celko tu dis, je pense que ça va être mon prochain achat :)
Non, il sait qu'il y a 1 et 2, donc le résultat est TRUE quel que soit le contenu du NULL.Citation:
Envoyé par skuatamad
Dans le même ordre d'idées, les tables de vérité de la logique tri-valuée (établies par Łukasiewicz) disent que TRUE OR UNKNOW est TRUE.
Ce bouquin ne contient pas de grande révélation foudroyante, mais il est très bien pour faire le point sur plein de petits détails de ce genre.Citation:
Envoyé par skuatamad
Effectivement, j'avais oublié la correspondance en expression logique des clause IN et NOT IN :
x IN(1,NULL,2)<=>x=1 OR x=NULL OR x=2
x NOT IN(1,NULL,2)<=>x!=1 AND x!=NULL AND x!=2
Et forcément avec des AND le résultat est UNKNOWN.