ADF 11g: Control de Cambios Pendientes en...

5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12

PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Newsletter – Octubre 2013

5a. Ave. 5-55 Zona14,Edificio Euro Plaza Torre II, Nivel 12

Teléfono: (502)2364-5300Fax: (502)2364-5311

[email protected] Pagina 1/10

ADF 11g: Control de Cambios Pendientes en Aplicación

Por Ing. Jonathan Morales

[email protected]

Al momento de desarrollar aplicaciones, es importante considerar ciertas situaciones que están fuera del control de las mismas, tal como los eventos con los botones del navegador. Supongamos que un usuario está ingresando datos a un formulario web, por lo que existe una transacción en curso desde el punto de vista de la aplicación. Pero sin haber grabado los cambios (commit), decide cerrar el navegador o refrescar la página. ¿Qué debe considerarse? En este punto cabe realizar el análisis de qué debería hacer la aplicación al respecto (tal como hacer un commit o rollback automático), pero como primer punto debe informarse al usuario que existen datos sin guardar o un proceso de la aplicación en curso; e impedir que la acción del navegador se ejecute sin confirmación del usuario. Para la situación anterior, Oracle ADF provee un mecanismo para verificar si existen cambios pendientes sin grabar y alertar en caso de un evento del navegador web: esto se logra gracias a la propiedad UncommittedDataWarning y la operación af:checkUncommittedDataBehavior. A continuación se mostrará como implementar dicha funcionalidad en una aplicación ADF 11g (ver figura), en la cual inicialmente al cambiar algún dato y cerrar o refrescar la página lo hace sin notificar. La aplicación posee un formulario y un botón de salir, en el cual también se hará la verificación de datos modificados.

Contenido

Página:

1 ADF 11g: Control de

Cambios Pendientes en

Aplicación

5 Operador PIVOT para

SQL de Oracle

9 Usuarios y Roles

Comunes/Locales en Oracle

12c

Editores Generales

Deiby Mauricio Gómez

Alejandro Lau

Debbie Morán

Autores

Contribuyentes

Jonathan Morales

Karlo Espinoza

Deiby Gómez


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Procedimiento

1. En la página jspx, en el panel de la estructura, seleccionar af:document y en las propiedades

buscar UncommittedDataWarning y colocarlo como ON.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Al ejecutar la aplicación, cambiar algún dato y al intentar refrescar la página se ve una notificación.

2. Para agregar la funcionalidad de notificar cuando existen cambios pendientes para un botón de

la aplicación (que pueda dirigir a otra página o bien salir), agregar la propiedad

af:checkUncommittedDataBehavior dentro del botón.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Si se presiona el botón de la aplicación y existen cambios pendientes, se mostrará el aviso:

3. Si se desea realizar algún proceso al presionar un botón de navegación, o bien realizar la

verificación desde un Backing Bean, se puede saber si existen cambios pendientes con el

siguiente código:

if(ControllerContext.getInstance().getCurrentRootViewPort().isDataDirty()){ //realizar procedimiento }

Probando la aplicación Al igual que en los casos anteriores, si se intenta cerrar el navegador luego de haber realizado cambios en los datos de la aplicación, se notificará que existen datos sin confirmar.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Operador PIVOT para SQL de Oracle

Por Ing. Karlo Espinoza

[email protected]

Parte esencial del uso de la información de una organización, sin importar su actividad principal, es la presentación de reportes. En muchas ocasiones es necesario trasladar información a hojas de cálculo y con las mismas obtener reportes recalculados mediante la creación de tablas pivote, permitiendo realizar análisis de resultados de datos, sumados en base a distintos criterios de comparación o análisis. La versión de base de datos Oracle 11g cuenta dentro de sus operadores SQL con PIVOT. Operador que se utiliza en consultas en las que se desea transponer información de las tablas consultadas. A continuación describiremos la función y ejemplos de uso de del operador. Las consultas pivote implican la transposición de filas en columnas para generar resultados en tablas de referencia cruzadas. Pivotear información es una técnica muy común, utilizada principalmente en reportes, y ha sido posible generarlas con SQL en versiones anteriores de Oracle. Pero la versión 11g incluye la palabra clave PIVOT, que es una extensión al comando SELECT, facilitando la implementación de la técnica de pivotear información para obtener y analizar resultados. Las consultas pivote calculan valores numéricos de alguna columna, utilizando valores de otra columna de la fila como criterio para realizar la función de agregación deseada. El operador PIVOT obtiene datos de filas diferentes, los agrega y convierte en columnas. Veamos la sintaxis utilizada para la clausula SELECT que utiliza el operador PIVOT. SELECT …

FROM …

PIVOT

{ cláusula_pivote

cláusula_pivote_FOR

cláusula_pivote_IN

}

A continuación la descripción de las tres nuevas cláusulas del operador PIVOT.

Cláusula_pivote: Define las columnas a ser operadas en grupo, PIVOT es una operación que

implica agregación de datos, ya sea sumar, contar, promediar, etc.

Cláusula_pivote_FOR: Define las columnas que van a ser agrupadas y pivoteadas.

Clausula_pivote_IN: Define el filtro para las columnas en clausula_pivote, el rango de valores en el que se limitarán los resultados, en otras palabras, las columnas que se van a generar. Las agregaciones para cada valor en la clausula_pivote serán transpuestas en una columna separada, que es a la que corresponde según el valor que tiene el registro en esa columna.

Veamos cómo funciona con un ejemplo. Para ello se crea una tabla llamada TEST_PIVOT, que contendrá los datos con los que se explica el ejemplo.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Ahora utilicemos la información de la tabla PIVOT_TEST para realizar una consulta que utilice el operador PIVOT. La forma básica del operador PIVOT es la siguiente:

Observe que las dos columnas que están seleccionadas en el SELECT interno se utilizan en la cláusula PIVOT. Se suma la información de la columna Quantity, y se forman columnas en base a


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

los valores de la columna Product_Code, que en este caso son 'A', 'B' y 'C', siendo estos valores los criterios de agrupación para realizar la función de agregación, en este caso una suma.

Note que se generan columnas para los valores de la columna Product_Code, los cuales aparecen como filas en la información de la tabla, que mediante el operador PIVOT, se convierten en columnas.

Si se requiere realizar un análisis más detallado, podemos simular un drill down, agregando una columna adicional en el SELECT, que no se utilice dentro de la cláusula PIVOT. En este caso agregamos CUSTOMER_ID.

Antes de la versión 11g, se podía obtener el mismo resultado utilizando la función DECODE combinada con funciones de agregación. SELECT SUM(DECODE(product_code, 'A', quantity, 0)) AS a_sum_quantity,

SUM(DECODE(product_code, 'B', quantity, 0)) AS b_sum_quantity,

SUM(DECODE(product_code, 'C', quantity, 0)) AS c_sum_quantity

FROM pivot_test

ORDER BY customer_id;

A_SUM_QUANTITY B_SUM_QUANTITY C_SUM_QUANTITY

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

210 90 160

1 row selected.

--Agregando la columna CUSTOMER_ID para similar drill down--

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

SELECT customer_id,

SUM(DECODE(product_code, 'A', quantity, 0)) AS a_sum_quantity,

SUM(DECODE(product_code, 'B', quantity, 0)) AS b_sum_quantity,

SUM(DECODE(product_code, 'C', quantity, 0)) AS c_sum_quantity


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

TIP TÉCNICO DEL MES: En Oracle Database 12c, dentro de un Contenedor (CDB) pueden existir muchas bases de datos de tipo Pluggable Database (PDB), cada una de estas bases de datos tienen un identificador único el cual puede ser consultado con la siguiente consulta:

SQL> select name, con_id from v$pdbs;

NAME CON_ID

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

PDB$SEED 2

PDB1 3

PDB2 4

El contenedor con ID=1 es el ROOT. Por Ing. Deiby Gómez [email protected]

FROM pivot_test

GROUP BY customer_id

ORDER BY customer_id;

CUSTOMER_ID A_SUM_QUANTITY B_SUM_QUANTITY C_SUM_QUANTITY

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

1 10 20 30

2 40 0 50

3 60 70 80

4 100 0 0

4 rows selected.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Usuarios y Roles Comunes/Locales en Oracle 12c

Por Ing. Deiby Gómez

[email protected]

En Oracle 12c el manejo de usuarios, roles y privilegios ha cambiado, ahora se tienen dos clases de usuarios y roles:

Usuarios y Roles Locales

Usuarios y Roles Comunes Y los privilegios ahora pueden ser asignados a usuarios comunes o locales, igualmente para los roles. Esto al principio puede ser ambiguo y un poco confuso. Este artículo explica en forma de reglas, el manejo de dichos usuarios y roles dentro de los contenedores en Oracle 12c. Requisito: Para crear usuarios comunes se debe poseer el privilegio "SET CONTAINER". La siguiente consulta muestra usuarios en la base de datos contenedora o raíz: SELECT USERNAME, COMMON FROM CDB_USERS;

La siguiente consulta muestra usuarios de una PDB específica. SELECT USERNAME, COMMON FROM DBA_USERS;

Regla No. 1: El nombre de un usuario común debe llevar el prefijo "C##". Prueba: Crear un usuario común sin prefijo "C##". SQL> CREATE USER DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL;

CREATE USER DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL

*

ERROR at line 1:

ORA-65096: invalid common user or role name

Regla No. 2: Un usuario local no puede crearse en la raíz. Prueba: Crear un usuario local en la raíz. SQL> CREATE USER DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=CURRENT;

CREATE USER DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=CURRENT

*

ERROR at line 1:

ORA-65049: creation of local user or role is not allowed in CDB$ROOT


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Regla No.3: Un usuario común no puede crearse en una PDB. Prueba: Crear un usuario común en una PDB. SQL> CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL;

CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL

*

ERROR at line 1:

ORA-65050: Common DDLs only allowed in CDB$ROOT

Regla No. 4: El nombre de un usuario local no puede llevar el prefijo "C##". Prueba: Crear un usuario local con prefijo C##. SQL> CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=CURRENT;

CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=CURRENT

*

ERROR at line 1:

ORA-65094: invalid local user or role name

Regla No. 5: Si se especifican objetos adicionales en la sentencia "CREATE USER", dichos objetos deben existir en todas las PDB's. Prueba: Especificar un DEFAULT TABLESPACE que no existe en todas las PDB's. SQL> select con_id, name from v$pdbs;

CON_ID NAME

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

2 PDB$SEED

3 PDB1

4 PDB2

SQL> SELECT TABLESPACE_NAME, CON_ID FROM CDB_TABLESPACES WHERE

TABLESPACE_NAME ='TBS_TEST';

TABLESPACE_NAME CON_ID

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

TBS_TEST 2

TBS_TEST 3

Como se ve, el tablespace TBS_TEST solo está creado en la raíz y en PDB1, pero no existe en PDB2. SQL> CREATE USER C##DEIBY IDENTIFIED BY MANAGER1 CONTAINER=ALL DEFAULT

TABLESPACE TBS_TEST;

CREATE USER C##DEIBY IDENTIFIED BY MANAGER1 CONTAINER=ALL DEFAULT

TABLESPACE TBS_TEST

*

ERROR at line 1:

ORA-65048: error encountered when processing the current DDL statement in

pluggable database PDB2

ORA-00959: tablespace 'TBS_TEST' does not exist


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Regla No. 6: Un usuario común puede crearse o borrarse aunque algunas PDBs no estén abiertas. Prueba: Crear un usuario común con una PDB montada. SQL> select con_id, name, open_mode from v$pdbs;

CON_ID NAME OPEN_MODE

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

2 PDB$SEED READ ONLY

3 PDB1 READ WRITE

4 PDB2 MOUNTED

Como vemos, PDB2 no está abierta o "READ WRITE". SQL> CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL;

User created.

El usuario se crea aunque PDB2 esté "MOUNTED", esto es posible debido al proceso de "sincronización" que Oracle hará cuando se abra PDB2. SQL> ALTER PLUGGABLE DATABASE PDB2 OPEN;

Pluggable database altered.

SQL> SELECT USERNAME, COMMON FROM DBA_USERS WHERE USERNAME='C##DGOMEZ';

USERNAME COMMON

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

C##DGOMEZ YES

Creación apropiada de usuario común:

Debe iniciar con "C##"

Debe ser creado en la raíz SQL> CREATE USER C##DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=ALL DEFAULT

TABLESPACE TBS_TEST;

User created.

Creación apropiada de usuario local:

No debe iniciar con "C##"

Debe ser creado en una PDB SQL> CREATE USER DGOMEZ IDENTIFIED BY MANAGER1 CONTAINER=CURRENT;

User created.

Nota: Si se omite la clausula "CONTAINER", el usuario se creará sin problemas y el tipo dependerá del contexto. Si se lanza la sentencia "CREATE USER" en la raíz, el usuario se creará como común; pero si se lanza en una PDB, el usuario será local. Conclusiones

Si una PDB está en estado "CLOSED", sus usuarios no son visibles (aun si son comunes), pues los metadatos son extraídos del tablespace SYSTEM de esa PDB.


PBX (502) 2364-5300 Fax (502) 2364-5311

[email protected]

Un usuario local puede existir en una y solo una PDB.

Un usuario local puede crear usuarios locales, pero no comunes.

Un usuario común puede crear usuarios locales y comunes.

Se puede crear usuarios locales con el mismo nombre en diferentes PDBs. Se llamarán igual pero son usuarios completamente diferentes.

Un usuario local no puede dar privilegios comunes.

Oracle sincronizará automáticamente los usuarios con las PDBs que estén cerradas.

ADF 11g: Control de Cambios Pendientes en...

Documents

Transcript of ADF 11g: Control de Cambios Pendientes en...