PutSQL 2025.5.31.15¶
Bundle¶
org.apache.nifi | nifi-standard-nar
Description¶
Exécute une commande SQL UPDATE ou INSERT. Le contenu d’un FlowFile entrant est censé être la commande SQL à exécuter. La commande SQL peut utiliser le ? pour échapper aux paramètres. Dans ce cas, les paramètres à utiliser doivent exister en tant qu’attributs FlowFile avec la convention de nommage sql.args.N.type et sql.args.N.value, où N est un entier positif. La valeur sql.args.N.type doit être un nombre indiquant le type de JDBC. Le contenu du FlowFile est censé être au format UTF-8.
Exigences en matière d’entrées¶
REQUIRED
Prend en charge les propriétés dynamiques sensibles¶
false
Propriétés¶
Propriété |
Description |
---|---|
Batch Size |
Le nombre préféré de FlowFiles à mettre dans la base de données en une seule transaction |
JDBC Connection Pool |
Spécifie le Connection Pool JDBC à utiliser pour convertir le message JSON en instruction SQL. Le Connection Pool est nécessaire pour déterminer les types de colonnes de base de données appropriés. |
Obtain Generated Keys |
Si c’est le cas, toute clé générée automatiquement par la base de données sera ajoutée au FlowFile qui l’a générée à l’aide de l’attribut sql.generate.key. Cela peut entraîner un léger ralentissement des performances et n’est pas pris en charge par toutes les bases de données. |
Support Fragmented Transactions |
Si c’est le cas, lorsqu’un FlowFile est consommé par ce processeur, celui-ci vérifie d’abord les attributs fragment.identifier et fragment.count de ce FlowFile. Si la valeur de fragment.count est supérieure à 1, le processeur ne traitera aucun FlowFile ayant ce fragment.identifier tant qu’ils ne sont pas tous disponibles ; à ce moment-là, il traitera tous les FlowFiles ayant ce fragment.identifier comme une seule transaction, dans l’ordre spécifié par les attributs fragment.index des FlowFiles. Cela permet d’assurer l’atomicité de ces instructions SQL. Si l’une des instructions de cette transaction génère une exception lors de son exécution, cette transaction sera annulée. Lorsque la transaction est annulée, aucune de ces FlowFiles n’est routée vers “success”. Si la propriété <Rollback On Failure> est définie sur “true”, ces FlowFiles resteront dans la relation d’entrée. Si la propriété <Rollback On Failure> est définie sur “false”, si l’un de ces FlowFiles est routé vers “retry”, tous ces FlowFiles seront routés vers “retry”. Dans le cas contraire, ils seront routés vers “failure”. Si cette valeur est “false”, ces attributs seront ignorés et les mises à jour se produiront indépendamment les unes des autres. |
Transaction Timeout |
Si la propriété <Support Fragmented Transactions> est définie sur “true”, spécifie combien de temps attendre que tous les FlowFiles pour un attribut fragment.identifier particulier arrivent avant de simplement transférer tous les FlowFiles ayant cet identifiant vers la relation “failure”. |
database-session-autocommit |
Le mode de validation automatique à définir sur la connexion à la base de données utilisée. Si cette propriété est définie sur “false”, l’opération ou les opérations seront explicitement validées ou annulées (en fonction respectivement du succès ou de l’échec) ; si elle est définie sur “true”, le pilote/la base de données gère la validation/l’annulation. |
putsql-sql-statement |
L’instruction SQL à exécuter. L’instruction peut être vide, être une valeur constante ou être construite à partir d’attributs à l’aide de l’Expression Language. Si cette propriété est spécifiée, elle sera utilisée quel que soit le contenu des FlowFiles entrants. Si cette propriété est vide, le contenu des FlowFile entrants doit contenir une instruction SQL valide, qui sera envoyée par le processeur à la base de données. |
rollback-on-failure |
Indiquer comment traiter les erreurs. Par défaut (faux), si une erreur survient lors du traitement d’un FlowFile, ce FlowFile sera routé vers la relation “failure” ou “retry” en fonction du type d’erreur, et le processeur pourra passer au FlowFile suivant. Au lieu de cela, vous voudrez peut-être annuler le traitement en cours sur le FlowFiles et arrêter immédiatement tout traitement ultérieur. Dans ce cas, vous pouvez le faire en activant la propriété “Rollback On Failure”. Si cette option est activée, les FlowFiles resteront dans la relation d’entrée sans être pénalisés et seront traités de manière répétée jusqu’à ce qu’ils soient traités avec succès ou supprimés par d’autres moyens. Il est important de définir une “Yield Duration” de manière adéquate afin d’éviter des réessais trop fréquents. |
Relations¶
Nom |
Description |
---|---|
failure |
Un FlowFile est routé vers cette relation si la base de données ne peut pas être mise à jour et qu’une nouvelle tentative d’opération est vouée à l’échec, par exemple en raison d’une requête non valide ou d’une violation de la contrainte d’intégrité |
retry |
Un FlowFile est routé vers cette relation si la base de données ne peut pas être mise à jour, mais une nouvelle tentative de l’opération peut être couronnée de succès |
success |
Un FlowFile est routé vers cette relation après la mise à jour réussie de la base de données. |
Écrit les attributs¶
Nom |
Description |
---|---|
sql.generated.key |
Si la base de données a généré une clé pour une instruction INSERT et que la propriété Obtain Generated Keys est définie sur “true”, cet attribut sera ajouté pour indiquer la clé générée, si possible. Cette fonctionnalité n’est pas prise en charge par tous les fournisseurs de bases de données. |