Página 1 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.[email protected]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
12
Embed
ADF 11g: Control de Cambios Pendientes en Aplicaciónnewsletter.datum.com.gt/wp-content/uploads/2013/10/Newsletter... · ADF 11g: Control de Cambios Pendientes en Aplicación Por
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Página 1
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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
Página 2
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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.
Página 5
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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.
Página 6
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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
Página 7
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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--
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]
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
Página 10
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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
Página 11
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
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.
Página 12
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12