¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Guía para la Redefinición Basada en Ediciones en Oracle 11G y posteriores: Consejos y Ejemplos de Uso de PD

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 67 Vistas
0
Cargando...

Definición: La redefinición basada en ediciones permite tener múltiples versiones de objetos PL/SQL, vistas y sinónimos en un solo esquema, lo que hace posible realizar actualizaciones de aplicaciones de base de datos sin tiempo de inactividad.

Estoy buscando cualquier pista o consejo para usar PD para modelar la Redefinición Basada en Ediciones en Oracle 11G r2 y posteriores.

¿Cómo estás gestionando las ediciones en el modelo? En nuestra situación mantenemos ramas para cada edición. La primera rama contiene la edición básica. Esta edición contiene desencadenadores. Las ediciones subsiguientes se crean a partir de la edición básica.

Tim Graham mantiene vistas del mismo nombre pero el código difiere de edición a edición. ¿Cómo manejas esto? Estas vistas utilizan diferentes nombres de columnas, tablas, etc.

¿Qué haces con los desencadenadores entre ediciones?

¿Cómo manejas los modelos PD para Ediciones?

Ejemplos sobre Ediciones:

CREATE EDITION e1

CREATE OR REPLACE PROCEDURE hello IS

BEGIN

DBMS_OUTPUT.PUT_LINE( 'Hola, edición 1.' );

END hello;

/

Si queremos usar la EDICIÓN "e1"

ALTER SESSION SET EDITION = e1;

Invocar procedimiento en la edición padre:

BEGIN hello(); END; / 

Resultado:

Hola, edición 1.  Procedimiento PL/SQL completado con éxito. 

**********************************************

CREATE EDITION e2

CREATE OR REPLACE PROCEDURE hello IS

BEGIN

DBMS_OUTPUT.PUT_LINE(' Hola, edición 2 .');

END hello;

/

si queremos usar la EDICIÓN "e2"

ALTER SESSION SET EDITION = e2;

Invocar procedimiento:

BEGIN hello(); END; / 

El hijo invoca su propia copia, el procedimiento real:

Hola, edición 2.  Procedimiento PL/SQL completado con éxito. 

************************************

En el siguiente ejemplo añadimos una nueva columna a una tabla base EMPLOYEE. La tabla base tiene la columna NOMBRE y contiene PRIMER NOMBRE y APELLIDO como contenido.

Para cambiar a la edición "release_v2" y probarlo.

Observación: La definición de la tabla employees solo tiene la columna NOMBRE.

ALTER SESSION SET EDITION = release_v2;

SELECT * FROM employees;

EMPLOYEE_ID NOMBRE FECHA_DE_N CÓDIGO_POSTAL

----------- ------------------------- --------- ----------

2 Peter Parker 01-ENE-10

Cambiamos a la edición "release_v3" y probamos.

Observación: La definición de la tabla employees tiene las columnas PRIMER_NOMBRE y APELLIDO.

SELECT * FROM employees;

EMPLOYEE_ID PRIMER_NOMBRE APELLIDO FECHA_DE_N CÓDIGO_POSTAL

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

2 Respuestas

0
Cargando...

Hi,

My suggestion

Given edition-based redefinition allows having multiple versions of PL/SQL objects, views and synonyms in a single schema, which makes it possible to perform upgrades of database applications with zero downtime.

Edition-based redefinition allows to redefine the copied objects in isolation. The changes do not affect users of the application. One database must have at least one edition.

Rules

Created or upgraded Oracle Database starts with one edition named ora$base. The parent of the first edition created with a CREATE EDITION statement is ora$base. The statement CREATE EDITION e2 creates the edition e2 as the child of ora$base.

An editioned object is a schema object that has both an editionable type and an editions-enabled owner. An edition can have its own copy of an editioned object, in which case only the copy is visible to the edition. All objects are editionable.

  • SYNONYM - Exception SYNONYM is an editionable type, a public synonym is a noneditioned object.
  • VIEW

All PL/SQL object types:

  • FUNCTION
  • LIBRARY
  • PACKAGE and PACKAGEBODY
  • PROCEDURE
  • TRIGGER
  • TYPE and TYPEBODY

A noneditioned object is a schema object that has a noneditionable type. An edition cannot have its own copy of a noneditioned object. A noneditioned object is identical in, and visible to, all editions.

Example: Table

It would be a natural fit to add a new field at the model level. I would call this new property "Edition". This property would contain a List of Values (Edition names). I should be able to select one of the editions already present or create a new one.

Depending on the edition chosen by default at the model level, we would have access to this edition objects and all ora$base objects - not edited - and all objects that have a noneditionable type - such as Table.

When creating a new edition object, I should be able to achieve an import or copy/paste from an object of a previous edition. The imported object should serve as a template, inspiration, and source.

Finally, I should be able to take cognizance of the previous editionable objects by selecting a LOV property at the object level.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Esto es un poco complicado....

Hoy en día, creo que la mejor manera de manejar esto es a través de ramas, cada rama representando la nueva edición. A medida que se realizan cambios en las ediciones "inferiores", pueden integrarse en las ediciones "superiores", mientras que las diferencias hechas en estas otras ediciones pueden mantenerse como instancias separadas.

Sin embargo, un soporte nativo de "ediciones" para SAP PowerDesigner podría ser interesante. Aunque no está planeado en este momento, estoy interesado en saber qué piensan los demás sobre esta capacidad y cómo la están utilizando hoy en día, para ver qué tipo de capacidad podríamos considerar para una futura versión.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?