Pourquoi ne PreparedStatement.setNull nécessite sqlType?
- Selon la java docs de PreparedStatement.setNull: "Remarque: Vous devez spécifier le paramètre de type SQL". Quelle est la raison que cette méthode nécessite le type SQL de la colonne?
- J'ai remarqué que le passage de java.sql.Les Types.VARCHAR fonctionne également pour les non-colonnes varchar. Existe-il des scénarios dans lesquels VARCHAR ne pas être approprié pour certains types de colonne ou de certains DB fournisseurs)?
Grâce.
OriginalL'auteur MosheElisha | 2010-11-22
Vous devez vous connecter pour publier un commentaire.
Pour un maximum de compatibilité; conformément à la spécification, il y a certaines bases de données qui ne permettent pas aux non NULLE d'être envoyé à la sous-jacentes de la source de données.
Je ne pense pas que ce genre de comportement est vraiment partie de la spécification ou si elle l'est, je suis sûr qu'il y est une certaine sorte de la coercition implicite y passe. En tout cas, en s'appuyant sur un tel type de comportement qui pourrait casser lorsque le sous-jacent la banque de données de changements n'est pas recommandé. Pourquoi ne pas simplement spécifier le type correct?
2. J'ai une méthode qui est une chaîne SQL et une Collection<Object>, et invoque PreparedStatement.setObject / setNull pour chaque objet. Si je veux que le type correct sera transmis à setNull j'ai besoin de passer le type de chaque objet et de créer un vilain si. Si le pilote de base de données peut gérer setObject, à mon avis, il doit gérer setNull et de vérifier aussi bien à l'interne.
Concernant 1; comme je l'ai déjà mentionné, JDBC est une tentative de normaliser l'interaction avec une base de données, mais à chaque base de données de mise en œuvre de sortir il y a sa propre façon de faire les choses. Pour l'e.g j'ai entendu dire que l'Oracle se plaint si un type n'est pas fourni lors de la définition de la valeur NULL. Donc JDBC nécessite de spécifier le type, si le sous-jacent JDBC de mise en œuvre de passe de la base de données est une autre chose. Il ne peut pas être aidé, si une base de données particulière wire protocol décide que les types de être transmises lors de la définition des valeurs NULL si il n'y a aucun point dans le raisonnement.
Concernant les 2; c'est une décision de conception qui vous avez fait. Je ne suis pas au courant de toute db helper/wrapper code/cadre qui tente de cacher types de base de données de l'utilisateur. En mode veille prolongée, vous devez spécifier les annotations/XML de configuration pour définir les types de colonne. Que diriez-ajout d'une fonctionnalité de votre code qui traite l'utilisateur a fourni des types? Si tout cela est vraiment gênant, il suffit de passer en VARCHAR, croiser les doigts et espérer pour le mieux. 🙂
OriginalL'auteur Sanjay T. Sharma
Pilotes JDBC semblent s'éloigner de
setNull. Voir Ajout du support pour setObject(<arg>, null).Ma liste de bases de données de soutien le plus logique comportement est:
Ma liste de bases de données en ne soutenant PAS cette logique de comportement est:
OriginalL'auteur user250343
Quand il s'agit de Oracle, il serait très imprudent de les utiliser varchar2 vers d'autres types de données. Cela peut tromper l'optimiseur et vous pourriez obtenir un mauvais plan d'exécution. Par exemple, le filtrage sur une colonne de date à l'aide d'un type de données timestamp dans votre lier, Oracle pourrait finir la lecture de toutes les lignes de la conversion de toutes les dates de timestamp, puis filtrer le voulait lignes de.
Si vous avez un indice sur la date de votre colonne, il pourrait même s'aggraver (si oracle a choisi de l'utiliser) - faire unique lit sur votre oracle des blocs.
--Lasse
OriginalL'auteur Lasse Jenssen