N'appelle pas ton sujet "blem", tu comprendras pourquoi ;-)
ça dépend, ta base de données est accessible comment ? Un connecteur ? Un EJB ?
Dans tous les cas, tu dois t'y connecter, et ça se fait en dur, alors tu sais ce que tu utilises. Tu essayes de faire quoi ?
KX
Messages postés19031StatutModérateur3 020
Bonjour,
"tu sais ce que tu utilises" Pas forcément, tu peux avoir des configurations dans des RAR (Resource Adapter aRchive) où il y a juste le JNDI exposé. Donc ce qui est "en dur" (même si on le mettra plutôt dans des .properties) c'est le JNDI, on ne sait pas forcément quelle base, user ou mdp il y a derrière. Ce qui est particulièrement pratique pour changer de base sans changer le code.
Pour récupérer le nom de la base de donnée, il faudrait faire une requête sur les tables systèmes de la base, ça dépendra du type de base de données et des droits d'utilisateurs que tu as (ou non).
"tu as un fichier de ressource pour la conf, c'est en dur..." Généralement ce que l'on appelle "en dur" c'est quand c'est inscrit dans le code, (au mieux dans des constantes, au pire directement dans les méthodes) donc on a aucun autre moyen de modifier la valeur que de recompiler et livrer le binaire.
Si on a un fichier de ressources où il y a juste à changer une valeur et redémarrer le programme pour la prendre en compte, on n'appelle pas ça "coder en dur" ;-)
"donc c'est quelque part" Oui, mais pas forcément où on a accès.
Dans ma boîte, si je demande un accès en base de données, je leur donne le JNDI que je veux, on me créé un user que je ne connais pas, un mot de passe que je connais encore moins et on me mets tout ça dans un fichier RAR sur le serveur où je n'ai pas accès...
Donc je ne sais pas quelle est ma base de donnée, mais à la limite je m'en fiche, et ils peuvent bien changer de base de données, de user ou mot de passe, que je n'en saurai rien, ça n'empêchera pas le programme de fonctionner.
Alors que si c'était vraiment en dur dans le programme...
Oui je sais bien, mais ce que j'entendais par "en dur", c'est que c'est écrit quelque part :)
Oui, mais pas forcément où on a accès. Dans ma boîte, si je demande un accès en base de données, je leur donne le JNDI que je veux, on me créé un user que je ne connais pas, un mot de passe que je connais encore moins et on me mets tout ça dans un fichier RAR sur le serveur où je n'ai pas accès...
Oh bah mince, je ne pensais pas que ça se passait comme ça. Mais je ne suis pas étonné :)
"tu sais ce que tu utilises"
Pas forcément, tu peux avoir des configurations dans des RAR (Resource Adapter aRchive) où il y a juste le JNDI exposé. Donc ce qui est "en dur" (même si on le mettra plutôt dans des .properties) c'est le JNDI, on ne sait pas forcément quelle base, user ou mdp il y a derrière. Ce qui est particulièrement pratique pour changer de base sans changer le code.
Pour récupérer le nom de la base de donnée, il faudrait faire une requête sur les tables systèmes de la base, ça dépendra du type de base de données et des droits d'utilisateurs que tu as (ou non).
Exemple en MySQL :
https://dev.mysql.com/doc/refman/8.0/en/getting-information.html
Je te rejoins là dessus, mais quand bien même tu as un fichier de ressource pour la conf, c'est en dur... donc c'est quelque part.
Généralement ce que l'on appelle "en dur" c'est quand c'est inscrit dans le code, (au mieux dans des constantes, au pire directement dans les méthodes) donc on a aucun autre moyen de modifier la valeur que de recompiler et livrer le binaire.
Si on a un fichier de ressources où il y a juste à changer une valeur et redémarrer le programme pour la prendre en compte, on n'appelle pas ça "coder en dur" ;-)
"donc c'est quelque part"
Oui, mais pas forcément où on a accès.
Dans ma boîte, si je demande un accès en base de données, je leur donne le JNDI que je veux, on me créé un user que je ne connais pas, un mot de passe que je connais encore moins et on me mets tout ça dans un fichier RAR sur le serveur où je n'ai pas accès...
Donc je ne sais pas quelle est ma base de donnée, mais à la limite je m'en fiche, et ils peuvent bien changer de base de données, de user ou mot de passe, que je n'en saurai rien, ça n'empêchera pas le programme de fonctionner.
Alors que si c'était vraiment en dur dans le programme...
Oh bah mince, je ne pensais pas que ça se passait comme ça. Mais je ne suis pas étonné :)
Merci pour l'explication.