Skip to content
Extraits de code Groupes Projets
Bifurcation depuis spip / spip
Le projet source a une visibilité limitée.
  • esj's avatar
    a6734f1e
    #209: les différents serveurs SQL n'ayant pas toujours la même syntaxe pour... · a6734f1e
    esj a rédigé
    #209: les différents serveurs SQL n'ayant pas toujours la même syntaxe pour les constantes, il faut confier aux fonctions d'abstractions leur représentation. Le problème se pose surtout pour l'instruction UPDATE. En conséquence, introduction d'un variante d'abstraction, '''sql_updateq''' qui reçoit un nom de table SQL, un tableau  ''champ => valeur'' et le descripteur de la table (qui peut être omise s'il s'agit d'une des tables principales), construit la représentation des constantes en fonction de leur type déclaré et effectue la requête. Pour les types '''datetime''' et '''timestamp''', les valeurs numériques sont considérées comme des dates, les autres comme une expression de date MySQL (NOW(), DATE_SUB etc), converties dans leur équivalent PG dans la version SPIP-PG. Une valeur numérique sera mise en apostrophes si le champ déclaré n'est pas numérique (contrairement à ce que fait '''_q()''' qui n'a pas l'information) mais exceptionnellement PG n'avait pas besoin de ça: un entier affecté à un texte y est converti en sa représentation comme en MySQL.
    
    Utilisation dans action/logout (seul endroit où on utilisait la fonction d'abstraction de update) et dans l'edition d'un article pour commencer. Reste à reporter partout où PG l'exige (il ne semble pas y en avoir tant que ça) voire partout pour être propre.
    a6734f1e
    Historique
    #209: les différents serveurs SQL n'ayant pas toujours la même syntaxe pour...
    esj a rédigé
    #209: les différents serveurs SQL n'ayant pas toujours la même syntaxe pour les constantes, il faut confier aux fonctions d'abstractions leur représentation. Le problème se pose surtout pour l'instruction UPDATE. En conséquence, introduction d'un variante d'abstraction, '''sql_updateq''' qui reçoit un nom de table SQL, un tableau  ''champ => valeur'' et le descripteur de la table (qui peut être omise s'il s'agit d'une des tables principales), construit la représentation des constantes en fonction de leur type déclaré et effectue la requête. Pour les types '''datetime''' et '''timestamp''', les valeurs numériques sont considérées comme des dates, les autres comme une expression de date MySQL (NOW(), DATE_SUB etc), converties dans leur équivalent PG dans la version SPIP-PG. Une valeur numérique sera mise en apostrophes si le champ déclaré n'est pas numérique (contrairement à ce que fait '''_q()''' qui n'a pas l'information) mais exceptionnellement PG n'avait pas besoin de ça: un entier affecté à un texte y est converti en sa représentation comme en MySQL.
    
    Utilisation dans action/logout (seul endroit où on utilisait la fonction d'abstraction de update) et dans l'edition d'un article pour commencer. Reste à reporter partout où PG l'exige (il ne semble pas y en avoir tant que ça) voire partout pour être propre.