Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
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
/** * 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
/** * 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
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
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
$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
$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
WHERE 'tablename'.'key' = value
à la place de
WHERE 'key' = value
en effet le champs key peut être présent plusieurs fois par exemple
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
Pages: 1