Restricciones de base de datos para consultas EJB
Las funciones de consulta EJB (Enterprise JavaBeans) deben adherirse a determinadas restricciones para las bases de datos.
Restricción de base de datos general
- Todos los enterprise beans relacionados con una consulta concreta deben correlacionarse con el mismo origen de datos. La consulta de EJB no soporta operaciones unificadas de varios orígenes de datos.
- Es posible que una sentencia del lenguaje de consulta
estructurado (SQL) generada por el programa de utilidad de generación del
código de despliegue de WebSphere Application Server para una consulta de
lenguaje de consulta de EJB ejbSelect devuelve filas en un conjunto de resultados que se compone de
valores nulos en todas las columnas.
Durante la ejecución, el gestor de persistencia en el tiempo guarda el conjunto recibido como resultado de esta consulta. Cuando la aplicación recupera la clave primaria del bean de resultado, el gestor de persistencia llama al extractor. El extractor es un método que es una clase generada de despliegue EJB. Este método devuelve un valor de 0 para entradas de columna nulas. Este valor se devuelve al contenedor EJB para reenviarlo a la aplicación. El contenedor EJB invoca la instancia de bean con el valor PK de 0. Esto podría crear un problema, ya que el usuario final no puede determinar si esta instancia de bean tiene un PK nulo o un valor PK de 0.
Para evitarlo, utilice la cláusula IS NOT NULL en la consulta finder para eliminar estos valores nulos del conjunto de resultados.
Restricciones específicas de base de datos
Distintos productos de base de datos colocan diferentes restricciones sobre los elementos que pueden incluirse en las sentencias de consulta de EJB. A continuación se ofrece una lista de esas restricciones; consulte con el administrador de la base de datos para averiguar si alguna es aplicable a su entorno:
- Ciertas funciones se utilizan en consultas que se ejecutan sólo contra DB2, porque estas funciones no están soportadas por otras bases de datos. Estas funciones incluyen expresiones aritméticas de fecha y hora, ciertas funciones escalares incluidas las que no aparecen en la lista como portables entre proveedores, y funciones escalares implícitas cuando se utilizan para correlacionar ciertos campos CMP (persistencia gestionada por contenedor). Por ejemplo, considere la correlación de un tipo numérico int con un campo de tipo decimal (5,2). Cuando se despliega contra una base de datos distinta a DB2, una consulta finder o select que contenga un campo CMP con esta correlación en particular falla, produciendo un mensaje de error que indica que no se puede ejecutar la consulta.
- El campo CMP de tipo string, cuando se correlaciona con un objeto CLOB (Character Large Object) de la base de datos, no se puede utilizar en operaciones de comparación porque la base de datos no soporta las comparaciones de CLOB.
- Las bases de datos pueden imponer límites a la longitud de los valores string que se utilizan como literales o como parámetros de entrada con los operadores de comparación. Estos límites pueden sacrificar el rendimiento de la consulta. Por ejemplo: En DB2, en la plataforma z/OS, la búsqueda "name = ?1" puede fallar si el valor de ?1 en tiempo de ejecución tiene una longitud superior a 255.
- La correlación de un tipo CMP numérico con una columna que contiene un tipo distinto puede dar lugar a resultados inesperados. Por ejemplo, consideremos la correlación del tipo numérico int con una columna de tipo decimal (5,2). Este escenario no conserva un valor decimal exacto (por ejemplo, el valor 12,25) durante el transcurso de la transferencia desde la base de datos al campo CMP del enterprise bean y de vuelta a la base de datos. Esta correlación provoca al sustitución del valor inicial por un número entero (en este caso, 12). En consecuencia, debe evitar la utilización del campo CMP en las operaciones de comparación cuando el campo CMP utiliza una correlación de esta naturaleza.
- Algunas bases de datos no soportan un tipo de datos que corresponda a la semántica de java.sql.Time. Por ejemplo: si un campo CMP de tipo java.sql.Time se correlaciona com una columna DATE de Oracle, las comparaciones de tiempo pueden no producir el resultado esperado porque la porción año-mes-día del valor de la columna se ha truncado en la correlación.
- Algunas bases de datos, tratan un valor de serie de longitud cero ( '' ) como un valor nulo y esto afecta a los resultados de las consultas. A efectos de portabilidad, no utilice valores de serie de longitud cero.
- Algunas bases de datos realizan una división entre dos valores enteros utilizando reglas aritméticas de enteros y mientras que otras utilizan reglas de no enteros. Esta discrepancia no es deseable en entorno s que utilizan ambos tipos de bases de datos. A efectos de portabilidad, no utilice la división de valores enteros en una consulta de EJB.
Los releases actuales de UDB DB2 para IBM i solo soporta un valor TIMESTAMP en formato "aaaa-mm-dd-hh.mm.ss.nnnnnn". Este valor no es compatible con el formato estándar soportado por la clase java.sql.Timestamp, que es "aaaa-mm-dd-hh mm.ss.nnnnnn". La función escalar TIMESTAMP debe utilizarse para convertir una representación de serie de un objeto java.sql.Timestamp a un valor que DB2 UDB para IBM i reconozca.