blog de luxspes

Reglas de Integridad

Cuando los datos se modifican con sentencias INSERT, DELETE o UPDATE, su integridad puede perderse de muchas maneras diferentes. Pueden añadirse datos no válidos a la base de datos, tales como un pedido que especifica un producto no existente.

Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios pueden ser aplicados parcialmente, como por ejemplo si se añade un pedido de un producto sin ajustar la cantidad disponible para vender.

Para evitar que la integridad de los datos se pierda, se pueden definir reglas que se encargaran de protegerla. Estas reglas pueden definirse en distintos niveles del código de la aplicación:

En Swing se puede navegar de un componente a otro usando las teclas Tab o Shift-Tab. Estas teclas son las "teclas de recorrido de foco" (focus traversal keys) y pueden ser cambiadas programaticamente. Por ejemplo, tu puedes agregar la tecla Enter a la lista de teclas de recorrido de foco con el siguiente codigo:

Y eso es todo, asi de facil se puede usar Enter en ves de tab para mover el foco al siguiente elemento. Simple no? Ahora trata de hacerlo con JavaScript en una forma de HTML:

No se puede. O tal ves si, pero nadie sabe como.
Hay algunas soluciones parciales, por ejemplo, esto solo funciona en IExplorer:

El proyecto Rel es una implementación del lenguaje Tutorial D de Date y Darwen en Java.

Rel es una verdadera RDBMS (no como Oracle, SQLServer o DB2 que son solo pseudo relacionales) con un lenguaje de consultas avanzado.
Rel es gratuito y opensource

Rel implementa un conjunto extendido del lenguaje propuesto por C. J. Date y Hugh Darwen, llamado Tutorial D. Es posible que ya lo hayas visto si alguna ves leíste el libro "Introducción a los Sistemas de Base de Datos" de Date.

El objetivo principal de Rel es como una herramienta de enseñanza, para que podamos explorar los conceptos de las bases de datos relacionales, pero lo que me impresiono sobre el, es que tras conocerlo se volvió imposible para mi el considerar a SQL como una lenguaje bien diseñado. Tutorial D te hace ver que SQL es una reliquia de de los 70 de la que ya deberíamos habernos deshecho hace mucho tiempo... y sin embargo, seguimos creando lenguajes para consultas lo mas parecidos a SQL que podemos, con el objetivo de facilitarle el aprendizaje a las personas que ya saben SQL, sin darnos cuenta que el aprender SQL en si mismo es una fuerte limitación a la productividad.

Empecemos con la operación relacional proyeccion: Veamos una comparación:

En SQL, puedo escribir:

Con lo que obtendré una consulta con las columnas a, b, c de la tabla r.

En Tutorial D dicha consulta se escribiría (en SQL es necesario escribir DISTINCT para garantizar que la salida no tenga redundancia, en Tutorial D, la redundancia esta prohibida por default por los principios Relacionales):

Que es mucho mas corto, hasta el momento, parece que esta es la única ventaja, pero ahora supongamos que la tabla "r" tiene los campos: a,b,c,d,e,f,g,h,i, y que solo queremos ver los campos d,e,f,g,h,i.

En SQL escribiria:

Mientras que en Tutorial D escribiria:

Vas a construir una nueva aplicación.. si eres como yo alguien que disfruta de las ventajas de la reutilizacion que te dan los proyectos opensource, y te estan pidiendo la tipica aplicacion web que tanto se acostumbra en estos tiempos... que haces?

Pues desde el principio ya estas pensando: Spring (o Weld si queres probar algo mas nuevo) para integrarlo todo, JPA para guardar en la base de datos... JSF, Wicket o Tapestry para la interfaz... y si tengo que poner mucha interactividad con Javascript? pues DWR!

Y construyes tu aplicación... Inclusive escribes un script de Ant para poder generar el .war que subiras (de forma tambie automatizada) al servidor de produccion...

Ignoremos por un momento los problemas que hayan podido surgir durante el desarrollo, y pensemos que llego el dia de finamente entrar "en produccion":

Tal vez hayas leido del acronimo RTFM, se utiliza en tipicamente (sobre todo en los foros de internet) cuando se le quiere indicar a alguien que para responder a su pregunta todo lo que tendria que haber hecho es leer el manual.

Bueno, quisiera proponerles un nuevo acronimo que me comento una amigo cuando estabamos platicando sobre los problemas a los que nos enfretamos todos los dias cuando estamos desarrollando: RTFS, la S es the StackTrace.

Cuando una aplicacion de Java se traba, en el 99% de los casos (a menos que le hayas logrado pegar a un bug de bajo nivel de la maquina virtual, cosa que ocurre muy pero muy rara vez)  la aplicacion te presentara a una StackTrace que te permitira saber no solamente en que linea ocurrio el problema, si no tambien que metodo(s) estaban llamando al metodo dentro del cual ocurrio el problema.

Digamos por ejemplo que  tenemos el metodo:

Que ocurre cuando el parametro object1 es null? Pues una NullPointerException, que se nos presentara de la siguiente forma:

Exception in thread "main" java.lang.NullPointerException
    at JavaSnippet$1.equals(JavaSnippet.java:5)
    at JavaSnippet$1.run(JavaSnippet.java:11)
    at JavaSnippet.main(JavaSnippet.java:14)

Ahi podemos ver que el error ocurrio en la linea 5 del archivo “JavaSnippet.java”, cuando la linea 11  del mismo archivo fue invocada por la la linea 14, inclusive nos dice a que metodo pertenece cada linea de ejecucion!

Algunas veces me he visto en discusiones del tipo de "por que usar Spring-JDBC" en un proyecto, si al final de cuentas con JDBC solito es "mas facil" y no hay necesidad de estar leyendo y aprendiendo a usar Spring-JDBC.

Es importante recordar que a menudo, el tiempo para que uno se toma aprender algo nuevo, acaba compensadose con el tiempo ahorrado gracias al nuevo conocimiento adquirido (Aunque tengo que admitir, que a menudo resulta dificil saber de antemano que las cosas resultaran asi).

Veamos el caso por ejemplo, de manejar una conexion (con el statement y resultset respectivos) desde adentro de una aplicacion corriendo en Tomcat.
Cual creen ustedes que es el modo correcto de hacerlo (sin JdbcTemplate, o ConnectionCallback o ninguna de esas "complicaciones" de Spring-Jdbc)

Asi?:

Necesito mejorar la estabilidad de mi conexión a Oracle desde Java mediante JDBC, hasta el momento, todo apunta a que la solución es actualizar la versión de mi driver JDBC. Parece una solución fácil, si no fuera por el Classpathhell que habita dentro de Tomcat, el application server mas usado en el lugar donde trabajo.

Al construir aplicaciones web en java, es muy importante manejar las conexiones a base de datos mediante connection pooling para hacer un uso adecuado de los recursos de la base de datos.

Tomcat cuenta con su propia implementacion de connection pooling que se puede aplicar a cualquier driver JDBC llamado DBCP, pero, desgraciadamente esta implentacion de pooling a menudo falla al cerrar las conexiones por lo que acaba desperdiciando recursos del servidor.

El Driver JDBC de Oracle cuenta con 2 modos de pooling que si bien son mas confiables a la hora de recuperar recursos tampoco estan libres de problemas: