Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

#1 08-02-2008 09:58:02

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

[Q] Zend_Db_Table_Abstract usage de const RESTRICT ?

dans la 1.5 je viens de voir la présence de
const RESTRICT
je me suis dit que comme je l'avais fait dans mes classe dérivé il y avait un mécanisme de restriction qui était prévu
dans les version précédente j'avais ajouté un

Code:

   /**
   * Restriction for query
   *
   * @var string
   */
   protected $_restrict = array();

une classe pouvant alors déclarer des condition à appliquer systématiquement sur la recherche dans la table.
comme par exemple

Code:

   /**
   * Restriction for query
   *
   * @var string
   */
   protected $_restrict = array(
      "'usr_end_date' >= now()"
   );

auquel cas toute les requêtes sur ma table par fetch find fetchAll et autre méthodes se retrouvaient automatiquement avec un where contraint par le contenu de $this->_restrict.

voyant apparaite cette constante dans la définition de la table je me demande s'il n'est pas envisagé un tel mécanisme
Or cette constante n'est pas utilisée. d'où ma question à quoi est-elle destinées.

je serait bien tenté de l'utiliser pour porter ce que j'ai fais dans la version 1.0.1 mais je me dis que si elle est destinée à un autre usage je vais introduire un conflit et ce n'est pas bon.

A+JYT

Dernière modification par sekaijin (08-02-2008 10:53:25)

Hors ligne

 

#2 08-02-2008 16:10:24

Julien
Membre
Date d'inscription: 16-03-2007
Messages: 501

Re: [Q] Zend_Db_Table_Abstract usage de const RESTRICT ?

Cette constante existe depuis longtemps.
Elle est utilisée pour assurer une intégrité référencielle hors SGBD ( on update restrict ).

En revanche pour ta question, la méthode _fetch() a été revue pour prendre en paramètre un nouvel objet : Zend_Db_Table_Select.

Hors ligne

 

#3 09-02-2008 14:57:56

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: [Q] Zend_Db_Table_Abstract usage de const RESTRICT ?

merci pour cette réponse
j'ai choisis pour gérer les restriction sur mes tables une constante propre à ma classe dérivée
FAST_RESTRICT

pour le _fetch je trouve simplement dommage qu'on ai pas prévu comme pour fetchRow la possibilité des garder la compatibilité ascendante dans cette dernière on à un paramètre non typé et c'est dans e corps de la méthode qu'on traite les deux syntaxe where ou select
si on avait simplement mi un paramètre sans type et levé une exception dans le corps
les classes dérivé ayant redéfinit la méthode _fetch pourraient garder leur prototype
il aurait suffit de les adapter si elle appelle la méthode parente et leur faire accepter la nouvelle syntaxe

là il faut non seulement les redéfinir mais aussi réécrire tout les code où elle sont utilisé.
c'est dommage.

Au passage je propose que soit ajouté le nom de la table dans la méthode find de Zend_Db_Table_Abstract
ligne 976 on

Code:

                    $whereAndTerms[] = $this->_db->quoteInto(
                        $this->_db->quoteIdentifier($keyNames[$keyPosition], true) . ' = ?',
                        $keyValue, $type);

or cette écriture peut dans certain cas introduire une ambiguité
je propose de mettre

Code:

                    $whereAndTerms[] = $this->_db->quoteInto(
                        $this->_db->quoteIdentifier($his->_name, true) . ' .',
                        $this->_db->quoteIdentifier($keyNames[$keyPosition], true) . ' = ?',
                        $keyValue, $type);

cela ne change pas grand chose juste que le code est

Code:

WHERE 'tablename'.'key' = value

à la place de

Code:

WHERE 'key' = value

en effet le champs key peut être présent plusieurs fois par exemple

Code:

SELECT 'tablename'.*
FROM 'tablename'
INNER JOIN 'tablename' AS parent ON ('tablename'.'parentid' = parent.'key')
WHERE 'key' = value
AND parent.'parentid IS NULL

dans ce cas possible avec Zend_Db_Table et Zend_Db_Table_Select on a un ambiguïté sur 'key'
pour pouvoir obtenir le résultat il faut alors systématiquement redéfinir la méthode find dès qu'on tombe sur ce genre de pb. préfixer les champs par le nom de la table voire le schemas résoudrait définitivement le problème dans toutes les requêtes.

A+JYT

Dernière modification par sekaijin (09-02-2008 14:58:57)

Hors ligne

 

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages