je viens de voir qu'en plus, avec la 1ère méthode (utiliser l'erreur de la contrainte) incrémentait néanmoins le compteur de ma clef primaire.
Je vais creuser le ON CONFLICT.
Merci beaucoup.
Cordialement,
Ramirez22
Je me pose une question bête.
J'ai créé une table avec des contraintes d'unicité sur plusieurs colonnes.
Lors de l'INSERT d'une nouvelle ligne, qu'est-ce qui est plus "propre"?
1- Faire l'INSERT et traiter le message de défaut qui arrivera en cas de doublon
2- Faire une vérification avant de faire l'insert (SELECT ...)
La deuxième option me semble plus "normale" : on ne s'appuie pas sur un garde fou système et on gère nous même l'unicité, quitte à avoir un défaut si un INSERT est réalisé par un autre utilisateur entre le SELECT et l'INSERT.
Mais du coup, dans mon application, j'ai 2 contrôles plus ou moins identiques :
- je fais d'abord un SELECT pour vérifier si tout est OK et je traite l'erreur le cas échéant
- je fais mon INSERT
- en cas d'erreur sur la contrainte d'unicité, je traite l'erreur de la même manière
Sans compter que la deuxième solution génère le double de trafic...
[Edit]Cependant, je viens de constater que l'incrémentation automatique de mon ID se faisait même en cas de présence de doublon (dans le cas de figure 1 ci-dessus). Ce qui risque de générer quelque "trous" dans mes ID...
Est-ce que c'est selon la sensibilité de chacun ou est-ce qu'il y a des règles particulières ?
Merci de votre attention.
Cordialement,
Ramirez22.