PEBKAC #8273

Alors que je configure un logiciel pour stocker les informations en base de données, après dix minutes PostgreSQL n'a rien dans la ventre, alors que je suis sûr de ma configuration, reprise d'une machine fonctionnelle.

Je maudis PostgreSQL et me lance alors avec MySQL. Ce n'est qu'après dix nouvelles minutes que je relis ma configuration ligne par ligne, et que je vois « sfacct_ip: 192.168.1.254 » au lieu de « 10.3.2.2 ».

Les données ne pouvaient effectivement jamais entrer dans la base… PEBKAC.

PEBKAC #8273 proposé par Thibault le 01/08/2013 | 11 commentaires | 👍🏽 👎🏽 +122

Les valeurs en dur dans le code c'est toujours un truc à se faire avoir...
(pour ça que faut vraiment prendre l'habitude de les mettre bien visible et le plus groupé possible)

Commentaire #104910 écrit par blag le 01/08/2013 à 17h42 | 👍🏽 👎🏽

Où c'est écrit que les valeurs sont en dur dans le code ?
Où c'est écrit que les valeurs ne sont pas bien visible et le plus groupé possible ?

Commentaire #104946 écrit par Moi le 01/08/2013 à 21h01 | 👍🏽 👎🏽

Je valide !

Commentaire #104949 écrit par védéhèm le 01/08/2013 à 21h40 | 👍🏽 👎🏽

Les valeurs sont dans un fichier de config a priori...

Commentaire #104958 écrit par neeko le 01/08/2013 à 23h26 | 👍🏽 👎🏽

> je relis ma configuration ligne par ligne, et que je vois sfacct_ip: 192.168.1.254

* Une relecture ligne par ligne pour trouver une erreur de set-variable, c'est que c'est pas placé là où ça devrais ou qu'il a pas chercher de manière la plus efficace.

* Le fait d'initialiser une variable avec une IP tapé à la main directement dans le code, c'est ce que j'appelle une valeur "en dur" (je t'accorde qu'elle est pas hard-codé dans chaque test, mais elle reste quand même saisie par le dev).

Commentaire #104959 écrit par blag le 01/08/2013 à 23h40 | 👍🏽 👎🏽

Pour moi, c'est plutôt dans un fichier de conf. À moins que « sfacct_ip: 192.168.1.254 » corresponde à une initialisation de variable dans un langage de programmation que je ne connais pas ?

Et puis, si c'est bien un fichier de conf, on ne sait pas quelle taille il fait. Parfois ils sont très longs, surtout s'ils sont bien commentés. Quand on ne sait pas où est le problème exactement, il n'y a pas d'autre choix que de se taper la lecture de dizaine de pages à la main.

Il faudrait les éclaircissements de Thibault sur le sujet.

Commentaire #104996 écrit par Moi le 02/08/2013 à 09h40 | 👍🏽 👎🏽

Le dev, ou le meilleur moyen de s'auto PEBKAC à longueur de journée quand on est étourdi :D

Commentaire #105194 écrit par Cid2Nice le 02/08/2013 à 22h32 | 👍🏽 👎🏽

Bon, pour rappel, j'avais testé PostgeSQL contre MySQL MyISAM et c'est bien MySQL qui est à privilégié (sauf si besoin d'un modèle pseudo objet et relationnel, à tester contre InnoDB)

Donc si tu peux te débrouiller avec MySQL, fais le. (Pour ma part, un SGBD ne doit faire que du stockage)

Commentaire #105215 écrit par Cartman34 le 03/08/2013 à 08h59 | 👍🏽 👎🏽

C'est quand même passer à côté de l'intérêt d'un SGBD : clairement un "système de gestion", et le réduire à ne "faire que du stockage" revient au bon vieux principe de la pêche à la dynamite. Certes, ça marche, mais on aurait pu rester avec une canne à pêche toute bête.

Commentaire #105442 écrit par audhulma le 04/08/2013 à 18h23 | 👍🏽 👎🏽

Ce n'est pas parce que tu n'utilises pas toutes ses fonctionnalités que tu le sous-utilises, elles sont ajoutées pour convenir à un maximum de développeur.
De plus, comment veux tu te passer d'un SGBD ? Tu te vois faire toi même les mises en cache, l'indexation et l'interprétation de requêtes SQL ? C'est aussi une question de performances.

Commentaire #105522 écrit par Cartman34 le 05/08/2013 à 11h55 | 👍🏽 👎🏽

Justement, ça n'est pas "juste du stockage".

Commentaire #105551 écrit par audhulma le 05/08/2013 à 13h24 | 👍🏽 👎🏽