Discussion :

[wagui31]

Bonjour

J'ai un petit souci avec Objet PreparedStatement en java pour insérer dans une base de donnée Oracle.

Enfaite je Prépare bien la model de ma requête INSERT dans le PreparedStatement j'ajoute bien tous mes paramètres avec un addBatch() pour chaque record je veux insérer .

j'ajoute plusieurs batchs pour Insérer d'un coups 500 records par exemple .

Jusque là tous marche bien j'arrive a insérer ce que je veux

Par contre dans le cas ou mon PreparedStatement génère une erreur BatchUpdateException (par exemple violation de contrainte) sur les 500 ligne que je veux insérer il m'insert rien du tout.

Moi je veux a la limite retirer le record qui pose souci(avec violation contrainte) et insérer au moins les 499 ligne qui sont OK

Je peu faire cela comment svp ? si qu'elle qu'un peu me donner une piste je serais reconnaissant.


Juste pour Info je veux bien insérer plusieurs lignes d'un coups a partir de 500 lignes, donc la solution d'insérer ligne par ligne ça m'arrange pas trop niveau performance
Cordialement

[adiGuba]

Salut,


La méthode getUpdateCounts() de BatchUpdateException t'indique le résultat de chaque requête.
Tu devrais pouvoir récupérer la (ou les) requête(s) fautives avec cela...


a++

[wagui31]

Salut,


La méthode getUpdateCounts() de BatchUpdateException t'indique le résultat de chaque requête.
Tu devrais pouvoir récupérer la (ou les) requête(s) fautives avec cela...


a++

Bonjour adiGuba
Merci pour ta réponse et désolé pour ma réponse tardive
Enfaite je ne vois pas vraiment comment je peu utiliser cette méthode dans mon cas (Pour retirer la requête fautives)
Exemple avec mon PrépareStatment je veux exécuter 10 requêtes et les 2 premières requête pose problème
donc je vais avoir une exception BatchUpdateException et la méthode getUpdateCounts() va me retourner un tableau avec une seule ligne [0] = -2
pour me dire que la 1ere requête ne passe pas
Donc --> Déjà exécution s'arrête a la 1ere requête qui pose problème et en plus elle va pas continuer a exécuter les 8 autres requêtes qui sont OK !!!
je ne sais pas si c'est plus clair avec mon exemple
Cordialement

[adiGuba]

Ben si tu arrives à déterminer la requête qui ne passe pas, tu peux régénérer tes batch en ignorant les requêtes déjà passé ou en erreur.

[wagui31]

Ben si tu arrives à déterminer la requête qui ne passe pas, tu peux régénérer tes batch en ignorant les requêtes déjà passé ou en erreur.

Ok donc y a pas moyen de dire je retire juste le batch qui pose souci et je continue exécution (genre deleteBatch(1)) c'est dommage de tout reconstruire je trouve, mais bon je vais me débrouiller.

En tous les cas j'ai remarqué si j'ai un PrépareStatement avec 500 Ligne a insérer et que c juste la dernière ligne qui pose problème il va insérer aucune ligne donc je suis obligé de détecté que c'est bien la dernière ligne qui pose pb et régénérer les 499 batch (reconstruire tout mon PrépareStatment) on est bien d'accord que c'est comme ça qu'il faut faire si j'ai bien compris ??

Merci a toi.

Cordialement,

[adiGuba]

Non si la dernière requête plante il t'aura inséré les 499 première, et getUpdateCounts() te retournera un tableau de 500 int.
A partir de là tu peux connaitre l'état de chaque requête et donc savoir celle qui sont passé ou pas.

Après la gestion dépend des drivers JDBC.
Certains s'arrêtent à la première erreur et n’exécutent pas les suivante, tandis que d'autre vont tout exécuter et remonter l'exception si une ligne a échoué...

[wagui31]

Non si la dernière requête plante il t'aura inséré les 499 première, et getUpdateCounts() te retournera un tableau de 500 int.
A partir de là tu peux connaitre l'état de chaque requête et donc savoir celle qui sont passé ou pas.

Après la gestion dépend des drivers JDBC.
Certains s'arrêtent à la première erreur et n’exécutent pas les suivante, tandis que d'autre vont tout exécuter et remonter l'exception si une ligne a échoué...

Ahhh je comprend mieux donc ça dépend du Drivers JDBC alors.
donc je pense dans mon cas mon driver se plante effectivement à la première erreur et n'exécute pas les suivantes (mais j'ai remarqué que quand il génère une erreur même les requêtes qui ont été exécutées avant échec ne sont pas comités j'ai impression qu'il commit a la fin si seulement il a bien tout exécuté)

Mais comment je fait la différence entre les drivers JDBC ? est ce que ta un lien stp pour télécharger un driver JDBC .jar qui justement permet d'exécuter tout et remonter l'exception a la fin ?

Cordialement

[fr1man]

Je dirais que c'est une question de gestion de transactions.
Soit tu fais une transaction par requête: pas très performant mais si une requête plante, elle n'empêche pas la bonne exécution des autres.
Soit tu fais une transaction pour plusieurs requêtes comme actuellement: dans ce cas, comme le dit adiGuba, il te faudra gérer toi même les erreurs et relancer ton batch.
C'est tout l'intérêt des transactions, on valide un ensemble de requêtes ou rien, pour éviter les incohérences.

[eulbobo]

Le driver JDBC ne changera rien, c'est son fonctionnement normal

Le fonctionnement du batchUpdate est de préparer un ensemble d'ordres SQL à envoyer en une seule fois dans une même transaction.
Si un seul plante, c'est normal qu'il y ait un rollback pour l'ensemble du paquet de données.




Une solution serait d'utiliser le même fonctionnement que Spring Batch pour ça (qui est une implémentation de l'API batch : http://www.oracle.com/technetwork/ar...h-1965499.html )

Tu fais tes mises à jour par paquets (500 par 500) (comme actuellement)
Si tout se passe bien pour un paquet, tant mieux
Si ton paquet plante, tu rééxécutes chaque requête du paquet de données à mettre à jour individuellement.

==> les paquets qui passent continuent d'être traités par lot
==> les paquets avec des données en erreur ont leur éléments rejoués un par un



Après, j'aurais aussi tendance à dire que tu devrais vérifier les contraintes d'intégrité en amont : une erreur BDD de ce type devrait toujours être considérée comme un bug et pas comme une façon de se dire "ha c'est déjà à jour"