Bonjour,

Dans le cadre d'une migration, je lis une base de données mysql qui contient plusieurs "database" qui contiennent les mêmes structures de table.

J'utilise donc la méthode get (nom dao, profil).

Pour mes tests, ma base ne contient qu'un seule "database" et un seul profil dans profiles.ini.

Par contre dans mon application j'essaie d'en lire plusieurs. La première existe mais les suivantes "NON". Le problème est que le programme ne "bronche" pas sur la deuxième "database" et reste sur le premier profil .

Comment détecter un profil ou une database qui n'existe pas ?

J'espère être clair...

Cordialement Denis

Bonjour,

pas très clair en effet...

Mais detecter un profil qui ne fonctionne pas, à priori, c'est simple : à la première requête, tu auras une exception PHP... À toi de la "catcher".

Bonjour,

laurentj a dit :
Bonjour,

pas très clair en effet...

Oui je sais mais le problème est difficile à expliquer même s'il est simple

Mais detecter un profil qui ne fonctionne pas, à priori, c'est simple : à la première requête, tu auras une exception PHP... À toi de la "catcher".

En fait, j'essaie d'instancier une DAO qui n'existe pas dans la base et/ou n'est pas déclarée dans profiles.ini. Donc je veux continuer le traitement, si le cas apparaît en l'indiquant dans message.log ou autre.

A+

Bonjour,

Bon j'attrape rien ;) !

try {
  $old_users = jDao::get("admin~i_utilisateur","ipbx_".$cli_old->name);
  $liste = $old_users->FindAll();
} catch (Exception $e) {
  jLog::log('Exception reçue : '.$e->getMessage());
  continue;
}

La variable $cli_old->name est récupérée via une table qui est dans un profil différent (donc database différente)
Quelque soit la valeur $cli_old->name , le profil reste toujours le dernier qui est déclaré dans profile.ini

À bientôt
Denis

Je comprend mieux ce que tu veux.

En fait, quand jProfile ne trouve pas le profil, il prend celui par défaut (celui nommé "default").

Si tu veux tester un profile, tu peux faire

try {
   // note bien le true qui indique ne pas prendre celui par défaut si il ne trouve pas
   $profile = jProfiles::get('jdb', $profilName, true);
   $found = true;
}
catch($e) {
   $found = false;
}

Bonjour,

Merci Laurent, je vais utiliser cette méthode de test
A+
Denis

Bonjour,

Je travaille avec Denis sur la migration évoquée dans ce sujet, et nous n'arrivons toujours pas à changer de profil dans la boucle.

C'est toujours le premier profil qui est pris en compte pour l'éxécution de la requête.

Voici le code source du script que nous utilisons :

// Search clients and users
		
$cli = jDao::get("admin~clients");
$CLI  = jDao::get("admin~m_ipbx", "mutty");

$mesCLI = $CLI->FindAll();

foreach($mesCLI AS $cli_old) {

	// Vérification de l'existence du profil pour la database
	try {
		$profile = jProfiles::get('jdb', "ipbx_".$cli_old->name, true);
	} 
	catch(Exception $e) {
		jLog::log('Exception reçue pour le profil : '.$e->getMessage());
		continue;
	}	
	
	// Ici le bon profil jdb est récupéré pour chaque client
	jLog::dump($profile,"profil : ");

	// Instanciation de la table source dans la database
	try {
		$old_users = jDao::get("admin~i_utilisateur",$profile['_name']);		
		// En revanche, ici on a toujours les enregistrements du premier profil, quelque soit le client
		$liste = $old_users->FindAll();
	} 
	catch (Exception $e) {
		jLog::log('Exception reçue pour la base : '.$e->getMessage());
		continue;
	}

}

Si quelqu'un a une idée, on est preneurs...

Merci !

Vous êtes sûr que les noms que vous donnez, ne sont ni des noms de section, ni des alias ? On est bien d'accord qu'ils n'existent nulle part dans le fichier ?

Un dump de votre fichier de profils aiderait à comprendre votre problème (sans les paramètres de login/pass/base/host .... ).

Quand tu dis "les noms que vous donnez", il s'agit bien des noms donnés aux profils ?

Voici un dump du fichier de profils :

[jdb]
; name of the default profile to use for any connection
default=admin

jacl2_profile=admin

[jdb:admin]
; the driver name : mysql, pgsql, sqlite...
driver=pgsql

; For most of drivers:
database=babelvoip
host=1.2.3.4
user=babelvoip
password=babelvoip
persistent=on

; when you have charset issues, enable force_encoding so the connection will be
; made with the charset indicated in jelix config
;force_encoding = on

; with the following parameter, you can specify a table prefix which will be
; applied to DAOs automatically. For manual jDb requests, please use the method
; jDbConnection::prefixTable().
;table_prefix =

; to use pdo
;usepdo=on

[jdb:fact]
; the driver name : mysql, pgsql, sqlite...
driver=mysql

; For most of drivers:
database=facturation
host=1.2.3.4
user=root
password=MdP
persistent=on

; when you have charset issues, enable force_encoding so the connection will be
; made with the charset indicated in jelix config
force_encoding = on

[jdb:mutty]
driver=mysql
database=mutty
host=1.2.3.4
user=root
password=MdP
persistent=off
force_encoding = on

[jdb:ipbx_os]
driver=mysql
database=ipbx_os
host=1.2.3.4
user=root
password=MdP
persistent=on
force_encoding = on

[jdb:ipbx_rika]
driver=mysql
database=ipbx_rika
host=1.2.3.4
user=root
password=MdP
persistent=off
force_encoding = on

[jdb:ipbx_arche]
driver=mysql
database=ipbx_arche
host=1.2.3.4
user=root
password=MdP
persistent=off
force_encoding = on

Ce qu'on essaye de faire, c'est donc de passer d'un profil ipbx_qqch à un autre, donc une base de données différentes mais avec une structure de tables et de champs à l'intérieur rigoureusement identique.

Cependant, même si le profil est bien récupéré correctement, les données renvoyées par jDao::get sont toujours celles correspondant à la table de la première base ipbx_qqch.

Si ce n'est pas assez clair, je peux toujours réexpliquer :)

je ne vois pas ce qui pourrais clocher. J'ai encore vérifié les tests unitaires sur jProfile, il n'y a pas de souci.

Cependant, même si le profil est bien récupéré correctement, les données renvoyées par jDao::get sont toujours celles correspondant à la table de la première base ipbx_qqch.

ça c'est rigoureusement impossible. Si il ne trouve pas le profil indiqué, au pire il renvoi le profil par défaut, ici "admin". Ou alors génère une exception. Mais il ne renvoi pas un autre profil.

Il y a un autre souci quelque part dans le code ou la configuration.