$sql.insert¶
Description¶
Exécute une requête de type INSERT et retourne une table contenant les clés primaires des nouvelles entrées
Mise à jour de dossier par SQL
Attention, les modifications apportées à un dossier par SQL ne sont pas automatiquement reprises au niveau du dossier chargé en mémoire. Cela peut amener à une désynchronisation entre les données de la base de données et celles du dossier chargé en mémoire dans la session.
Il est important de forcer le moteur à recharger les données mémoire à
partir de la base de données au moyen de la méthode
$data.reload.
Erreur ORA-00933: SQL command not properly ended
Les insertions multiples peuvent générer une erreur sur certains SGBD. C'est notamment le cas avec Oracle lorsque l'on tente d'exécuter le code suivant:
La base de données retourne dans ce cas une erreur ORA-00933: SQL command
not properly ended. En réalité la requête est parfaitement correcte et
le problème ne vient pas de la requête, mais de l'usage de $sql.insert
qui n'est pas approprié pour ce type de requête.
👉 En cas d'insertion multiple, il faut utiliser la méthode
$sql.update.
Explication:
La méthode $sql.insert demande au SGBD de retourner les clés primaires
des lignes insérées (ces dernières sont reprises dans la réponse de la
méthode). Pour indiquer au driver qu'il souhaite recevoir ces clés, le
moteur crée le prepared statement avec un flag
Statement.RETURN_GENERATED_KEYS. Dans le cas du driver JDBC d'Oracle,
cela a pour effet de transformer la requête en:
Le problème est que la syntaxe RETURNING ... INTO n'est valide que
pour un INSERT ... VALUES (...) (une seule ligne). Elle n'est pas
supportée avec INSERT ... SELECT (insertion multiple).
La méthode $sql.update n'active pas le flag en question
et ne provoque pas d'erreur.
Syntaxe¶
$sql.insert( query [ , data [ , options ] ] )
Paramètres¶
querystring- Requête à évaluer
dataarray / map / string / number / date / time / timestamp / file-
Jeu de données à passer à la requête (dans le cas où la requête utilise la notation des prepared statements - ce qui est recommandé)
Le paramètre peut prendre plusieurs formes en fonction de la requête sur laquelle il doit s'appliquer:
- Valeur
null: La requête n'attend pas de paramètre ou n'utilise pas la syntaxe des prepared statement - Valeur litérale unique: La requête n'attend qu'un seul paramètre de type simple (string, number, date, time, timestamp ou file)
- Tableau 1D: Dans ce cas, les valeurs du tableau sont reprises dans l'ordre comme valeurs pour le prepared statement.
- Tableau 2D (tableau de tableau 1D) : La méthode comprend que l'on
souhaite évaluer plusieurs fois la requête. Elle boucle sur les lots
de données dans l'ordre et évalue la requête avec chacun des lots
disponibles. Par exemple, si le tableau vaut
[[1,2],[3,4]], la méthode va évaluer la requête 2 fois : la première fois avec les valeurs 1 et 2, et la seconde fois avec les valeur 3 et 4. - Map : Ce cas s'applique si la requête référence des paramètres nommés.
- Tableau de map : Cette syntaxe permet de passer plusieurs jeux de données à la fois, en utilisant la notation avec des paramètres nommés. Dans ce cas, la méthode est évaluée autant de fois qu'il y a de maps dans le tableau.
Veuillez prendre connaissance de la note traitant de la valeur
nulldans la documentation de$sql.select. - Valeur
optionsmap-
Map d'options supplémentaires. Les options reconnues sont:
batchboolean-
Demande à la méthode d'exécuter le statement en tant que batch, avec auto-commit désactivé (un commit global est réalisé à la fin de traitement du batch).
Ce mode apporte un gain de performances significatif lorsqu'il s'agit d'insérer de grandes quantités de données (voir l'exemple 2 donné plus bas).
Par contre les
datane peuvent être fournis que sous la forme d'une matrice (c-à-d. un tableau de tableaux). Si les données contiennent des maps, le traitement ne sera pas effectué sous forme de batch.En outre, la valeur de retour ne fournira pas de détail sur les insertions effectuées. La méthode retourne simplement
true. timeoutnumber- Temps maximum (en secondes) autorisé pour l'exécution de la requête
connectionstring- Nom de connexion de laquelle tirer les paramètres de connexion. Doit référencer une connexion définie dans le fichier de configuration
dumpLevelstring- Cette option permet d'afficher la requête dans le log. La valeur
de l'option doit désigner un niveau de log parmi (
trace,debug,info,warnouerror)
Retour¶
Matrice contenant les valeurs des clés générées. Retourne true si le mode
batch est activé.
⚠️ Attention, le retour de la méthode peut varier selon le type de SGBD utilisé. Ainsi sur SQLite, la valeur de retour est un array ayant la forme suivante:
Cette valeur ne constitue pas la clé primaire de la table, mais elle permet de retrouver le tuple généré au moyen d'une requête du genre
où pk1, pk2, etc. sont les colonnes contenant la clé primaire et
table est le nom de la table sur laquelle l'insertion a été faite.
Exemple¶
Exemple 1¶
Le code ci-dessus génère la trace de log suivante (peut varier en fonction de la configuration du logger) et effectue une insertion dans la table indiquée:
WARN - ch.epilogic.ewt.scripts.library.EwtScriptLibSql.log():238 - insert into sample(col1, col2) values(1, 'o''reilly')
Exemple 2¶
Le code ci-dessous donne un exemple qui compare le temps d'exécution pour l'insertion de 20'000 entrées sur une table.
Le script génère les traces suivantes: