Paramètres de compatibilité – ou conduire avec le frein à main serré (Partie 1)

Dans les cuisines de code, je passe généralement un certain temps avec les paramètres de la base de données, en particulier avec les paramètres de compatibilité. Souvent, certains paramètres ne respectent pas les meilleures pratiques et lors des discussions avec le développeur de l’application, j’entends « oh, je n’ai jamais changé ces paramètres » ou « je ne suis pas sûr de l’impact, donc mieux vaut ne pas y toucher ».

Comme ils peuvent avoir un impact considérable sur les performances ou le comportement de vos applications, nous avons commencé une série d’articles de blog pour discuter de certains de ces paramètres « secrets« .

Première partie des paramètres de compatibilité – QUERY BY FORMULA

Ces paramètres obligent 4D à se comporter comme dans la version 2004, ce qui réduit les fonctionnalités et les performances. Et il est si facile de les modifier, mais les clients ont peur des effets secondaires inconnus.

QUERY BY FORMULA était assez lente dans la v2004 (car tous les enregistrements étaient transférés au client), sans grande valeur ajoutée. En conséquence, la plupart des développeurs l’ignoraient. Les règles ont changé avec la v11.

La commande QBF (pour faire court dans ce billet de blog) vous permet d’utiliser des calculs tels que la recherche de la taille d’une image ou de la longueur d’un texte. Les avantages de cette fonctionnalité sont assez évidents. Cependant, les calculs de ce type ne peuvent pas utiliser d’index, ils sont donc plus lents qu’une requête indexée.

Mais la commande QBF peut faire beaucoup plus ! Elle peut combiner des groupes de requêtes avec des parenthèses : ((champ1=1) et (champ2= »A »)) OU ((champ1=50) et (champ2= »B »)).

Ne pas utiliser la commande QBF signifie exécuter deux requêtes et utiliser des groupes, ce qui entraîne un trafic réseau beaucoup plus important, une plus grande dépendance vis-à-vis des performances du réseau et une plus grande charge pour le serveur 4D. L’optimiseur de requêtes de 4D Server détecte automatiquement la meilleure façon (la plus rapide) de traiter de telles conditions sur les champs d’une même table – ou même de tables connexes.

Et surtout, il peut établir des relations par lui-même (c’est-à-dire des jointures), même si aucun lien n’est établi en mode structure. Oui, vous pouvez construire des relations de manière dynamique pour exécuter des requêtes (si l’option « QUERY BY FORMULA Uses SQL Joins » est activée).

L’option « QUERY BY FORMULA Uses SQL Joins » peut prêter à confusion parce qu’elle n’est pas du tout liée à SQL, vous devriez plutôt la considérer comme « QBF supporte les relations dynamiques ».

Prenons l’exemple d’une structure simple :

Tant QUERY et QUERY BY FORMULA peuvent être utilisés pour effectuer une recherche en utilisant une relation, par exemple :

QUERY BY FORMULA([Table_2];[Table_1]Field_2= "1" )

Mais seul QBF vous permet de définir explicitement la relation (permettant l’utilisation de toute relation possible), au lieu d’exiger qu’une relation définie existe déjà. Imaginons maintenant qu’il existe une deuxième connexion logique entre ces deux tables, mais qu’elle n’existe pas déjà en tant que relation 4D … Champ3 avec Champ2. QBY vous permet de spécifier la relation à la volée :

QUERY BY FORMULA([Table_2]; ([Table_1]ID=$var)& \
([Table_1]Field_2=[Table_2]Field_3))

Note : Lorsque l’on utilise des jointures dynamiques, il faut comparer deux champs de tables différentes. Si cela fait partie d’une requête, cela est automatiquement traité comme une jointure, pour définir une relation.

Si vous souhaitez rechercher une valeur dans une autre table, vous devez d’abord l’affecter à une variable locale. Cela permet de définir clairement que vous voulez l’utiliser comme constante.

L’activation de l’option « QUERY BY FORMULA Uses SQL Joins » est obligatoire pour permettre au « nouvel » éditeur de requêtes(c’est-à-dire l’éditeur de requêtes introduit avec la v14) d’utiliser les relations. La raison en est simple, il utilise la commande QUERY BY FORMULA en interne.

Résumé :

• QUERY BY FORMULA permet d’utiliser des parenthèses pour exprimer des conditions de requête complexes, alors que QUERY permet uniquement des conditions OR ou AND multiples, mais pas une combinaison des deux.
• QUERY BY FORMULA supporte les jointures et les requêtes dynamiques.
• QUERY BY FORMULA permet l’utilisation de formules, telles que la taille de l’image.
• QUERY BY FORMULA est exécuté sur le serveur (comme une application normale de type QUERY), offrant la même vitesse, voire une meilleure vitesse, car elle génère moins de trafic réseau par rapport à une combinaison d’opérations OR et AND. QUERY et d’opérations de set.

Remarque : tout ce qui précède est vrai pour le langage 4D classique. Le code basé sur ORDAest toujours exécuté sur le serveur.

Travail de migration nécessaire pour activer la compatibilité

Les paramètres ci-dessus ne sont visibles dans la boîte de dialogue Compatibilité que pour les structures créées avec 4D v2004 ou une version antérieure. Si vous ne voyez pas ces paramètres, votre structure est plus récente et se comporte toujours en mode v11, donc vous pouvez y aller !

Utilisez l’option Find en mode conception pour rechercher les éléments suivants QUERY BY FORMULA. Comme votre structure est en mode « lent » v2004, la liste devrait être courte. Double-cliquez sur chaque résultat et vérifiez le code.

Tant que la formule utilise des constantes, telles que :

QUERY BY FORMULA([Table_2];[Table_1]Field_2= "1" )

Ou

QUERY BY FORMULA([Table_2];[Table_1]Field_2=$var) // similar for var or <>var

Tout va bien, il n’y a rien à faire. 4D Remote va interpréter la variable et envoyer son contenu au serveur (comme une constante). La valeur du client est toujours utilisée, même si la requête est exécutée par le serveur.

Si la formule est une méthode, telle que :

QUERY BY FORMULA([Table_2];RunQuery)

Vous devez ouvrir et vérifier le contenu de la méthode. Si des paramètres sont passés à la méthode, il y a de fortes chances que la méthode soit générique (mais vous devez quand même vérifier). Si aucun paramètre n’est passé, il y a de fortes chances que la méthode échoue.

Imaginons que RunQuery contienne :

$0:= ([Table_2]=myvar)

Le contenu de myvar sera différent sur 4D Remote et 4D Server, donc l’exécution de cette méthode sur 4D Server échouera. Elle renverra des résultats différents.

Il existe deux façons de résoudre ce problème. Pour les requêtes simples comme ci-dessus, vous pouvez simplement réécrire la méthode comme RunQuery(myvar) et utiliser $1 dans la méthode. Problème résolu.

Mais vous pourriez trouver une méthode vraiment complexe. Des milliers de lignes de code, aucune documentation, écrite il y a 20 ans. Et utilisée seulement une fois par an. C’est beaucoup de travail et de risques d’erreurs, pour un impact minimal. Pour contourner le problème, vous pouvez choisir de n’exécuter ce code qu’en mode v2004, tout en gardant tout le reste en mode moderne :

SET DATABASE PARAMETER(Query by formula on server;1)
QUERY BY FORMULA ([Table_2];RunQuery )
SET DATABASE PARAMETER (Query by formula on server;0)

SET DATABASE PARAMETER permet de changer le mode à la volée, évitant ainsi de passer des heures sur du code rarement utilisé.

Enfin, vous devez vérifier si les champs sont utilisés d’une manière qui nuit à la fonction de jointure. Avec la v2004, une formule telle que [Table_1]Field_2=[Table_2]Field_3 est interprétée comme une recherche de contenu statique/fixe, utilisant le contenu du champ_3. Après avoir activé l’option « QUERY BY FORMULA Uses SQL Joins », cette formule est interprétée comme une jointure.

Vous devez donc vérifier chaque QBF pour voir s’il utilise un nom de champ à droite d’un opérateur « = ». Si c’est le cas, affectez-le à une variable locale et utilisez la variable locale dans la requête.

Après avoir vérifié toutes les occurrences de QUERY BY FORMULAvous êtes prêt à activer les deux options.

Profitez d’une recherche rapide…