Des astuces Doctrine/DQL - Historique des versions

BeTa le 22 mars 2013 à 19:56

2013-03-22T19:56:29Z

← Version précédente		Version du 22 mars 2013 à 19:56
Ligne 306 :		Ligne 306 :
	Cela nous donne bien le resultat escompté.		Cela nous donne bien le resultat escompté.

	[Catégorie:Informatique]		[[Catégorie:Informatique]]

BeTa le 24 octobre 2012 à 11:09

2012-10-24T11:09:30Z

← Version précédente		Version du 24 octobre 2012 à 11:09
Ligne 305 :		Ligne 305 :

	Cela nous donne bien le resultat escompté.		Cela nous donne bien le resultat escompté.

			[Catégorie:Informatique]

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

2012-09-06T14:50:56Z

Faire des recherches multi-critères sans tenir compte des accents

← Version précédente		Version du 6 septembre 2012 à 14:50
Ligne 131 :		Ligne 131 :
	== Faire des recherches multi-critères sans tenir compte des accents ==		== Faire des recherches multi-critères sans tenir compte des accents ==

	Créer un objet vous permettant de spécialiser votre mode de recherche :		Créer un objet vous permettant de spécialiser votre mode de recherche (par exemple dans lib/model) :

	class MySearchAnalyzer extends Doctrine_Search_Analyzer_Utf8		class MySearchAnalyzer extends Doctrine_Search_Analyzer_Utf8
Ligne 139 :		Ligne 139 :
	$charset = sfContext::getInstance()->getConfiguration()->charset;		$charset = sfContext::getInstance()->getConfiguration()->charset;
	$text = strtolower(iconv($charset['db'],$charset['ascii'],$text));		$text = strtolower(iconv($charset['db'],$charset['ascii'],$text));

	return parent::analyze($text);		return parent::analyze($text);
	}		}
Ligne 145 :		Ligne 145 :


	Ajouter une fonction dans le Doctrine_Record de votre objet :		Ajouter une fonction dans le Doctrine_Record de votre objet (dans lib/model/doctrine) :

	public function setUp()		public function setUp()
Ligne 155 :		Ligne 155 :
	}		}

	Créer une Task Symfony permettant de mettre à jour vos tables d'index :		Créer une Task Symfony permettant de mettre à jour vos tables d'index (ex: lib/task/SearchIndexTask.class.php) :

	<?php		<?php
Ligne 204 :		Ligne 204 :
	}		}
	}		}

			N'oubliez pas de remettre le cache de Symfony à zéro :

			./symfony cc

	== Ajouter des parenthèses arbitraires dans une Doctrine_Query ==		== Ajouter des parenthèses arbitraires dans une Doctrine_Query ==

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

2012-09-06T14:49:29Z

Faire des recherches multi-critères sans tenir compte des accents

@@ Ligne 131 : / Ligne 131 : @@
 == Faire des recherches multi-critères sans tenir compte des accents ==
-TO COME
+Créer un objet vous permettant de spécialiser votre mode de recherche :
 == Ajouter des parenthèses arbitraires dans une Doctrine_Query ==

BeTa : /* Solution pratique et fonctionnelle */

2011-01-17T12:27:24Z

Solution pratique et fonctionnelle

← Version précédente		Version du 17 janvier 2011 à 12:27
Ligne 120 :		Ligne 120 :
	}		}
	}		}

			=== Conclusion ===

			Avec cette solution, la manipulation des objets et de leurs champs d'objets ''serialized'' se fait de manière totalement transparente par rapport au système "standard" de Doctrine. Elle se fait également de manière totalement transparente, que votre application Doctrine fonctionne sur PostgreSQL, MySQL ou autre.

	== Faire des recherches sans tenir compte des accents ==		== Faire des recherches sans tenir compte des accents ==

BeTa : /* Solution pratique et fonctionnelle */

2011-01-17T12:23:05Z

Solution pratique et fonctionnelle

← Version précédente		Version du 17 janvier 2011 à 12:23
Ligne 30 :		Ligne 30 :

	=== Solution pratique et fonctionnelle ===		=== Solution pratique et fonctionnelle ===

			Le cas pratique et fonctionnel qui va suivre est issu du schema.yml suivant :

			==== schema.yml ====

			EmailSpool:
			package: email
			actAs: [Timestampable]
			columns:
			message:
			type: text
			notnull: true
			priority: integer

			à noter le "package" email qui amène un fonctionnement de Doctrine particulier.

			==== email/EmailSpool.class.php et email/EmailSpoolTable.class.php ====

			// EmailSpool.class.php
			class EmailSpool extends PluginEmailSpool
			{
			public function setMessage($message)
			{
			$msg = unserialize($message);
			$this->priority = $msg->getPriority();

			return parent::setMessage($message);
			}
			}

			// EmailSpoolTable.class.php
			class EmailSpoolTable extends PluginEmailSpoolTable
			{
			// ...
			public function getSpooledMessages()
			{
			return $this->createQuery('m')
			->orderBy('m.priority')
			;
			}
			}

			Jusque là que du très normal.

			==== packages/email/PluginEmailSpool.class.php ====

			L'idée est donc de gérer "plus haut" la question de l'échappement des informations à insérer en base. Puisque c'est '''\0''' qui pose problème, nous allons donc remplacer cet octet par une autre chaîne qui ne posera pas problème (ex: ''~~NULL_BYTE~~''), et prévoir son contre-échappement.

			Ici nous travaillerons donc sur le champ '''PluginEmailSpool::message''' en surchargeant les méthodes '''setMessage()''' et '''getMessage()'''. Pour garder à l'esprit la souplesse de l'ORM Doctrine, cette surcharge ne doit être efficiente que dans le cas où le driver utilisé est celui de PostgreSQL. Nous ajouterons donc les méthodes '''getDBDriver()''' et '''isPgsql()''' :

			abstract class PluginEmailSpool extends BaseEmailSpool
			{
			protected $db_driver = '';
			const null_byte = "~~NULL_BYTE~~";

			protected function getDBDriver()
			{
			if ( !$this->db_driver )
			$this->db_driver = Doctrine_Manager::connection()->getDriverName();
			return $this->db_driver;
			}
			protected function isPgsql()
			{
			return 'Pgsql' === $this->getDBDriver();
			}

			public function setMessage($message)
			{
			if ( $this->isPgsql() )
			$message = $this->pg_escape_serialized($message);

			return $this->_set('message',$message);
			}

			public function getMessage()
			{
			return $message = $this->isPgsql()
			? $this->pg_unescape_serialized($this->_get('message'))
			: $this->_get('message');
			}

			static protected function pg_escape_serialized($str)
			{
			return str_replace("\0", self::null_byte, $str);
			}
			static protected function pg_unescape_serialized($str)
			{
			return str_replace(self::null_byte, "\0", $str);
			}
			}

	== Faire des recherches sans tenir compte des accents ==		== Faire des recherches sans tenir compte des accents ==

BeTa : /* Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea */

2011-01-17T12:01:36Z

Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea

← Version précédente		Version du 17 janvier 2011 à 12:01
Ligne 17 :		Ligne 17 :
	==== Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea ====		==== Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea ====

	L'interfaçage de PHP avec les "lo" (''large objects'') rend les choses complexes, puisque c'est une '''resource''' qui nous ait retournée. ~~Si jamais~~ vous allez jusqu'à lire dans cette '''resource''' (de la nature de celle qui est retournée par '''fopen()'''), le problème des '''\0''' sera toujours présent.		L'interfaçage de PHP avec les "lo" (''large objects'') rend les choses complexes, puisque c'est une '''resource''' qui nous ait retournée. Déjà cela change profondément et radicalement le comportement originel de Doctrine. Ensuite, même si vous allez jusqu'à lire dans cette '''resource''' (de la nature de celle qui est retournée par '''fopen()'''), le problème des '''\0''' sera toujours présent.

	==== Travailler directement dans son Doctrine_Record avec pg_escape_bytea() ====		==== Travailler directement dans son Doctrine_Record avec pg_escape_bytea() ====

BeTa : /* Solution pratique */

2011-01-17T12:00:33Z

Solution pratique

← Version précédente		Version du 17 janvier 2011 à 12:00
Ligne 29 :		Ligne 29 :
	$object = unserialize(pg_unescape_bytea($field));		$object = unserialize(pg_unescape_bytea($field));

	=== Solution pratique ===		=== Solution pratique et fonctionnelle ===

	== Faire des recherches sans tenir compte des accents ==		== Faire des recherches sans tenir compte des accents ==

BeTa : /* Solutions envisagées */

2011-01-17T12:00:05Z

Solutions envisagées

← Version précédente		Version du 17 janvier 2011 à 12:00
Ligne 12 :		Ligne 12 :

	=== Solutions envisagées ===		=== Solutions envisagées ===

			Plusieurs solutions viennent alors à l'esprit :

			==== Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea ====

			L'interfaçage de PHP avec les "lo" (''large objects'') rend les choses complexes, puisque c'est une '''resource''' qui nous ait retournée. Si jamais vous allez jusqu'à lire dans cette '''resource''' (de la nature de celle qui est retournée par '''fopen()'''), le problème des '''\0''' sera toujours présent.

			==== Travailler directement dans son Doctrine_Record avec pg_escape_bytea() ====

			Cette solution permet d'enregistrer apparemment correctement les objets en base, puisque cette fois le champ incriminé contient a priori bien toutes les données que nous attendions. Cependant il est impossible de faire correctement appel à :

			$object = unserialize($field);

			Même l'utilisation de '''pg_unescape_bytea()''' n'améliore pas la situation car cela plante tout autant :

			$object = unserialize(pg_unescape_bytea($field));

	=== Solution pratique ===		=== Solution pratique ===

BeTa : /* Problématique */

2011-01-17T11:53:48Z

Problématique

← Version précédente		Version du 17 janvier 2011 à 11:53
Ligne 4 :		Ligne 4 :

	=== Problématique ===		=== Problématique ===

			Dans une [http://www.libre-informatique.fr/sw/01-Billetterie/e-venement webapp] développée sur le framework Symfony, il est question d'envoyer des courriels via la factory SwiftMail. La stratégie choisie est de passer par un spooler afin de différer l'envoi des courriels sans surcharger l'interface utilisateur.

			SwiftMail embarque une gestion de spooler assez efficace : Elle génère les objets Swift_Message qui, au lieu d'être envoyés directement, sont stockés en base "as-is" via la function PHP '''serialize()'''. Seulement, si vous faîtes l'essai, vous ne retrouverez que les premiers octets de votre objet en base, et ce quel que soit le type de champ que vous aurez choisi (blob/bytea, string/text, etc...).

			Après de bonnes investigations, j'ai trouvé que c'était les caractères '''\0''' qui posaient problème. Doctrine ne les échappe pas "naturellement" ou correctement et PostresSQL y est intolérant.

	=== Solutions envisagées ===		=== Solutions envisagées ===

Des astuces Doctrine/DQL - Historique des versions

BeTa le 22 mars 2013 à 19:56

BeTa le 24 octobre 2012 à 11:09

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

BeTa : /* Solution pratique et fonctionnelle */

BeTa : /* Solution pratique et fonctionnelle */

BeTa : /* Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea */

BeTa : /* Solution pratique */

BeTa : /* Solutions envisagées */

BeTa : /* Problématique */

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

BeTa : /* Faire des recherches multi-critères sans tenir compte des accents */

BeTa : /* Solution pratique et fonctionnelle */

BeTa : /* Solution pratique et fonctionnelle */

BeTa : /* Spécifier clairement le type '''bytea''' dans le '''schema.yml''' au lieu du type Doctrine bytea */

BeTa : /* Solution pratique */

BeTa : /* Solutions envisagées */

BeTa : /* Problématique */