Restrictions de la base de données pour les requêtes EJB
Les fonctions de requête EJB (Enterprise JavaBeans) doivent obéir à certaines restrictions pour les bases de données.
Restrictions générales concernant la base de données
- Tous les beans enterprise impliqués dans une requête donnée doivent être mappés vers la même source de données. La requête EJB ne prend pas en charge les opérations de jointure entre plusieurs sources de données.
- Il est possible qu'une instruction SQL générée par l'utilitaire de génération de
code de déploiement de WebSphere
Application Server
pour une requête EJB-QL ejbSelect renvoie, sous forme d'ensemble de
résultats, des lignes
constituées de valeurs Null dans toutes les colonnes.
En phase d'exécution, le gestionnaire de persistance mémorise ce jeu en tant que résultat de la requête. Lorsque votre application extrait la clé primaire du bean de résultat, le gestionnaire de persistance appelle l'extracteur. L'extracteur est une méthode qui constitue une classe générée par le déploiement EJB. Cette méthode renvoie la valeur 0 pour chaque entrée de colonne de type Null. Cette valeur est passée au conteneur EJB pour la transmettre à l'application. Le conteneur appelle l'instance de bean avec la valeur PK 0. Ceci peut poser un problème puisque l'utilisateur final ne peut pas déterminer si cette instance de bean a une valeur PK Null ou une valeur PK de 0.
Pour éviter cette situation, utilisez la clause IS NOT NULL dans la requête de recherche de sorte à éliminer les valeurs Null du jeu de résultats.
Restrictions spécifiques concernant la base de données
Les différentes base de données appliquent des restrictions différentes quant aux éléments qui peuvent être inclus dans les instructions des requêtes EJB. Voici une liste de ces restrictions ; consultez votre administrateur de base de données pour savoir si certaines d'entre elles s'appliquent à votre environnement :
- Certaines fonctions sont utilisées uniquement dans les requêtes destinées à être exécutées sur DB2, car elles ne sont pas prises en charge par les autres bases de données. Ces fonctions sont notamment les expressions arithmétiques de date et d'heure, certaines fonctions scalaires (celles qui ne sont pas répertoriées comme étant portables entre fournisseurs), et les fonctions scalaires implicites lorsqu'elles sont utilisées pour le mappage de certains champs CMP. Par exemple, prenons le mappage d'un type numérique int vers une zone de type décimal (5,2). En cas de déploiement sur une base de données autre que DB2, une requête de sélection ou de recherche contenant une zone CMP avec ce mappage spécifique échoue et génère un message d'erreur Cannot push down query (impossible de transmettre la requête).
- Une zone CMP de type String, lorsqu'elle est mappée vers un objet CLOB dans la base de données, ne peut pas être utilisée dans les opérations de comparaison car la base de données ne prend pas en charge les comparaisons de données CLOB.
- Les bases de données peuvent imposer des limites quant à la longueur des valeurs de chaîne pouvant être utilisées en tant que littéraux ou en tant que paramètres d'entrée avec des opérateurs de comparaison. Ces limites peuvent nuire aux performances des requêtes. Par exemple, dans le cas de DB2 sur z/OS, la recherche "name = ?1" peut échouer si la valeur de ?1 au moment de l'exécution est d'une longueur supérieure à 255.
- Le mappage d'une zone CMP de type numérique vers une colonne qui contient un type différent peut produire des résultats inattendus. Par exemple, prenons le cas du mappage du type numérique int (entier) vers une colonne de type décimal (5,2). Ce scénario ne garantit pas la conservation d'une valeur décimale exacte (par exemple, la valeur 12.25) au cours du transfert depuis la base de données vers la zone CMP du bean enterprise, puis de retour vers la base de données. Ce mappage entraîne le remplacement de la valeur initiale par un nombre entier (en l'occurrence, 12). Par conséquent, vous devez éviter d'utiliser la zone CMP dans les opérations de comparaison lorsque cette zone utilise un mappage de cette nature.
- Certaines bases de données ne prennent pas en charge les types de données correspondant à la sémantique de java.sql.Time. Par exemple : Si une zone CMP de type type java.sql.Time est mappée vers une colonne DATE Oracle, les comparaisons portant sur les données de temps peuvent ne pas produire le résultat prévu du fait que la partie year-month-day de la valeur de la colonne est tronquée lors du mappage.
- Dans certaines bases de données, une valeur de chaîne de longueur nulle ( '' ) est traitée comme une valeur nulle, ce qui affecte les résultats des requêtes. Pour préserver la portabilité, évitez d'utiliser des chaînes de longueur nulle.
- Certaines bases de données effectuent une division entre deux entiers à l'aide de règles arithmétiques spécifiques aux entiers, tandis que d'autres utilisent des règles spécifiques aux nombres autres qu'entiers. Cette différence peut ne pas être souhaitable dans des environnements qui utilisent ces deux types de bases de données. Pour préserver la portabilité, évitez la division des valeurs entières dans une requête EJB.
Les versions actuelles d'UDB DB2 for IBM i ne prennent en charge qu'une valeur TIMESTAMP au format "aaaa-mm-jj-hh.mm.ss.nnnnnn". Ce format n'est pas compatible avec le format standard pris en charge par la classe java.sql.Timestamp, qui est "aaaa-mm-jj-hh mm.ss.nnnnnn". La fonction scalaire TIMESTAMP devrait être utilisée pour convertir une représentation sous forme de chaîne d'un objet java.sql.Timestamp en une valeur reconnaissable par DB2 UDB for IBM i.