Estrategia para administrar paquetes Oracle sin romper el código

Question

Tengo curiosidad por saber cómo las personas administran sus paquetes en sus aplicaciones.

Por ejemplo, en nuestra instancia de desarrollo, un desarrollador de aplicaciones puede desear cambiar un procedimiento almacenado. Sin embargo, al cambiar el procedimiento almacenado se romperá el código de Java existente hasta que la capa de DAO se actualice para adaptarse a los cambios.

Mi práctica habitual ha sido poner la implementación del nuevo procedimiento en un paquete "DEV". El desarrollador puede cambiar su referencia a este paquete, hacer sus pruebas y luego, cuando estemos listos, podemos reemplazar el procedimiento en el paquete de "producción", eliminarlo de DEV y el desarrollador cambia su referencia al paquete de producción.

Sin embargo, me parece que no funciona tan bien como me gustaría. Primero, si hay un montón de código Java que depende del paquete DEV, entonces estoy en la misma situación que si estuviera editando el paquete de producción directamente; si rompo el paquete, romperé un montón de código.

En segundo lugar, la gente se ocupa y no podemos mover el paquete a la producción lo antes posible. Luego tenemos dos versiones del procedimiento almacenado flotando y se hace difícil recordar qué se ha movido a producción y qué no.

El objetivo es mantener a los desarrolladores trabajando. Sí, es un servidor de desarrollo, pero no queremos romper código inesperadamente.

¿Alguien puede sugerir metodologías que les hayan funcionado para solucionar este problema?

Answer 1

Si cada desarrollador tiene su propio esquema en la base de datos y hay sinónimos públicos para todos los objetos en el esquema compartido y todo el código Java usa nombres de objetos no calificados, entonces una copia local del paquete en un esquema de desarrollador particular tendrá prioridad sobre la versión compartida. Entonces el desarrollador A puede tomar la versión actual del paquete, instalarlo en su esquema local, hacer los cambios que desee en el paquete y hacer los cambios necesarios en Java dentro de su propio entorno de desarrollo (supongo que los desarrolladores) tener su propio servidor de aplicaciones local). Cuando ambos conjuntos de cambios son lo suficientemente estables como para poder incorporarlos al entorno de desarrollo compartido, tanto el paquete PL/SQL como los cambios Java se pueden construir en el entorno de desarrollo compartido (el servidor de la aplicación de desarrollo compartido y el esquema real en la base de datos de desarrollo). El desarrollador puede soltar su copia local del paquete.

Ese enfoque funciona razonablemente bien siempre que los desarrolladores estén verificando el PL/SQL fuera del control de fuente para comenzar sus cambios en lugar de suponer que cualquier copia local que tengan en su esquema sea actual-- si los desarrolladores se mantienen viejos, locales versiones de código en su esquema local, pueden terminar con problemas difíciles de depurar donde sus versiones PL/SQL y Java no están sincronizadas. Puede resolver ese problema automatizando procesos que, por ejemplo, eliminen paquetes de esquemas de desarrollador si no se han modificado en un período de tiempo razonable y si el desarrollador no ha revisado esos paquetes en control de fuente o creando scripts eso permite que un desarrollador automatice la actualización de su esquema como parte del proceso de compilación.

Answer 2

La capa Java/DAO solo debe verse afectada si la especificación del procedimiento cambia (es decir, número, nombre, etc. de los parámetros). Las estrategias de mitigación para esto son

1. añadir nuevos parámetros con valores por defecto para los parámetros de modo que no tienen que pasar.
2. No cambie el orden de los parámetros si se llaman de forma posicional [p. Ej. Pkg.proc_a (1,2,3)], o cámbieles el nombre si se llaman por nombre [p. Ej. Pkg.proc_b (p_1 => 1, p_2 => 2)]

3. Use paquetes para procedimientos y funciones para que pueda sobrecargarlos

   crear o sustituir paquete es proc (p1 en varchar2); proc (p1 en varchar2, p2 en número); final;

Con sobrecarga puede tener varios procedimientos con el mismo nombre en un paquete acaba con diferentes números y/o tipos de datos de los parámetros

11gR2 ha introducido editioning para resolver este problema. Permite múltiples versiones de paquetes y el código de la aplicación elige qué 'edición' (versión) del código quiere ver: la edición 'base' predeterminada o una versión de desarrollo.

Sin embargo, sospecho que la actualización de la versión de la base de datos no es una solución práctica.