SQL : différences entre LEFT JOIN, RIGHT JOIN, etc

J’ai toujours eu quelques diffuculté a bien visualisé les différence qu’il y avait entre left join, right join, join, etc lorsque je fait des requêtes SQL. Aujourd’hui je suis tombé sur un exemple frappant, et je me suis dit que cela pouvait en aider plus d’un! Comme une image vaux mieux qu’un long discours, en voici l’essence.

L’exemple suivant se base sur une base de donnée mysql :

CREATE TABLE IF NOT EXISTS `acl_roles` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(30) CHARACTER SET utf8 NOT NULL,
`build_on` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `build_on` (`build_on`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO `acl_roles` (`id`, `name`, `build_on`) VALUES
(1, 'guest', NULL),
(2, 'normal', 1),
(3, 'modo', 2),
(4, 'admin', 3);

ALTER TABLE `acl_roles` ADD CONSTRAINT FOREIGN KEY (`build_on`) REFERENCES `acl_roles` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Nous avons donc une table avec des clefs de référence pour marquer les dépendance entre les roles. En images cela donne ceci :

id name build_on
1 guest NULL
2 normal 1
3 modo 2
4 admin 3

Maintenant regardons le résultats de divers SELECT, le résultat parle de lui-même.

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar, acl_roles arp WHERE arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar LEFT JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
1 guest NULL NULL
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar RIGHT JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo
NULL NULL NULL admin

J’espère que l’exemple servira a certain et que cela en aidera plus d’un!

ZF : ACL et ressources multiple

Lorsque l’on utilise des ACL dans Zend Framework, une chose assez embêtante est de devoir tout mettre en place1. Pour ma part, j’ai par facilité voulu ajouté le support de ressource multiple.

Avant de commencer, il convient de contextualisé les choses, les ACL de ZF pouvant être utilisé de bien des manière.

Dans le cas qui nous intéresse, j’ai simplement défini ceci :

  • les ressources2 = module.controller
  • les privilèges3 = action

Ce que je voulait c’est pouvoir définir une ressource pour tous les contrôleurs. La syntaxe évidente qu’il m’est venu est la suivante : module.*

Dans ma classe qui étend Zend_ACL j’ai simplement fait ceci :

    public function isAllowed($role = null, $resource = null, $privilege = null)
    {
    	if (null === $resource)
    		return parent::isAllowed($role, $resource, $privilege);
 
    	$resources = $this->getResourcesPossibility($resource);
    	foreach($resources as $resource)
    	{
    		if ($this->has($resource) && parent::isAllowed($role, $resource, $privilege))
    		{
    			return true;
    		}
    	}
    	return false;
    }
 
    public function getResourcesPossibility($resource = null)
    {
    	$ret = array($resource);
    	if (null !== $resource)
    	{
    		$resources = explode('.', $resource);
    		$cptRessources = count($resources);
    		if ($cptRessources >= 2)
    		{
    			$resources[ $cptRessources - 1 ] = '*';
    		}
    		$ret[] = implode('.', $resources);
    	}
    	return $ret;
    }

Ceci peut bien entendu être enrichi mais permet au moins de profiter de l’utilisation des ACL dans le menu et sur des aides de vue qui serait éventuellement définie comme expliqué dans la plupart des tutoriaux.

Pour en savoir plus sur les ACL et Zend Framework, je vous renvoi a un très bon article.

  1. surtout si on utilise l’aide de vue pour généré un menu (Zend_navigation)
  2. resource
  3. privilege

ZF : module et autoloader

Avec Zend Framework, lorsque l’on travail un projet conséquent il devient vite utile de travailler avec le mécanisme des modules. Celui-ci permet d’étendre pas mal de chose et surtout une séparation poussée en … module.

Le problème de ce mécanisme1 est qu’il faut définir le chemin pour le chargement automatique à l’aide de ceci :

$autoloader = new Zend_Application_Module_Autoloader(array(
	'namespace' => 'SuperModule',
	'basePath'  => 'path to super module',
));

Je vous propose donc de faire une petite amélioration afin que ce chargement soit fait automatiquement.

Avant tout, dans votre configuration (ici en .ini) vous devez au moins avoir ceci de présent :

resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
resources.modules =

Ensuite, à la base de chaque dossier module créer un fichier Bootstrap.php2 :

<?php
class SuperModule_Bootstrap extends Grummfy_Bootstrap{}
# EOF

Et pour finir créer le fichier3 library/Grummfy/Bootstrap.php

<?php
 
abstract class Grummfy_Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
	protected function _initAutoload()
	{
		$className = get_class($this);
		$zf_namespace = explode('_', $className);
		$reflector = new ReflectionClass($className);
		$autoloader = new Zend_Application_Module_Autoloader(array(
			'namespace' => $zf_namespace[0],
			'basePath'  => dirname($reflector->getFileName()),
		));
		return $autoloader;
	}
}
 
# EOF
  1. sauf si j’ai loupé un truc…
  2. ne pas oublier de changer le nom du module …
  3. n’oubliez pas de déclarer le « namespace » Grummfy ou bien d’inclure le fichier

ZF : génération automatique du fichier de navigation et ACL

Lors de l’utilisation du mécanisme d’ACL et de génération de menu dans Zend Framework, il est intéressant de limiter l’affichage de ce menu en utilisant les ressources et privilèges associer.

Pour ma part, j’utilise un fichier XML pour construire mon menu, mon sitemap, … 1. Et comme beaucoup je génère mon projet ZF à l’aide de Zend_Tool. Je trouvais donc dommage de devoir réécrire pratiquement la même chose que ce que j’avais déclaré dans Zend_Tool pour reconstruire mon menu. J’ai donc décidé de rapidement écrire un petit script qui reprendrait le fichier XML du projet et le transformerait en menu …

À noter que le script devrait certainement être amélioré, mais que cela permet un gain de temps considérable …

Téléchargement

  1. Comme expliquer dans le manuel http://framework.zend.com/manual/fr/zend.navigation.html

Réécriture d’URL, alias et plusieurs développeurs sur Apache

Lorsque l’on travaille à plusieurs sur un projet, c’est toujours intéressant. Malheureusement, cela peut aussi entrainer divers problèmes. Je vais tenter de vous expliquer un obstacle qui peut vite devenir très chi*nt…

Pour présenter cette problématique, je vais prendre exemple sur ce que je développe actuellement. Le site en cours de création se base sur zend framework et nécessite une réécriture d’URL. Il faut savoir qu’Apache utilise le chemin physique1 comme base pour calculer le chemin vers le fichier réécrit sauf si on lui précise une directive RewriteBase différente. Le problème survient à cet endroit, plusieurs développeurs entrainent plusieurs machines et donc plusieurs configurations différentes!

La solution de base est que chaque personne utilisant un alias Apache définit un RewriteBase. Cependant, cela veut dire qu’a chaque nouvelle version du fichier .htaccess il faut redéfinir celui-ci.

La réponse la plus simple consiste à utiliser un RewriteCond sur l’hostname du serveur et bien entendu à l’utiliser lors de l’accès aux tests locaux ou non …

Exemple de configuration :

  • nom du serveur : grummfy
  • URL appelée : http://grummfy/serveur/dev/projet/example.com/… (Si vous utilise http://localhost/ la directive HTTP_HOST vaudra localhost)
  • ALIAS : /serveur/ => /media/data/serveur/

Le fichier .htacccess contiendra ceci :
SetEnv APPLICATION_ENV development
php_value session.auto_start 0
php_flag magic_quotes_gpc off
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteCond %{HTTP_HOST} grummfy
RewriteRule ^.*$ /serveur/dev/projet/example.com/index.php [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Le fait d’utiliser le rewrite flag « L » permet de sortir de la réécriture d’URL. Si le hostname du serveur n’est pas grummfy il appliquera la règle par défaut, à savoir tenter de trouver index.php dans /media/data/serveur/dev/projet/example.com/ comme si on avait effectuer un appel depuis http://media/data/serveur/dev/projet/example.com/

  1. physical-directory-path