SQL Developer y la interfaz para trabajar con GIT: Interactuando con un repositorio GitHub Parte 2

En este post voy a mostrar la manera de sincronizar los repositorios remoto (GitHub) y local (PC) una vez que un archivo existente en local es modificado. Lo que voy a hacer es modificar el archivo sp_test_git.pls que se encuentra en el repositorio local y luego voy a transferir los cambios al repositorio remoto.

En primer lugar debo abrir el archivo sp_test_git.pls en SQL Developer, luego agrego otra línea dbms_output y finalmente guardo los cambios. En el momento que el archivo es modificado, la ventana Pending Changes (Git) se actualiza para reflejar los cambios y los íconos de la ventana se activan.

modify_file

En la ventana  Pending Changes (Git) puedo añadir un comentario y luego transferir el archivo a un área temporal (staging area) haciendo click en el botón Add. Algo que hay que notar es el cambio en el status del archivo que pasó de “Modified Not Staged” a “Modified Staged”.

staged_file

¿Qué hago si deseo si deseo comparar las versiones del archivo antes de confirmar los cambios en el repositorio local? Solamente debo hacer click en el ícono Compare with Previous Version que se encuentra en la ventana Pending Changes (Git).

compare2

El panel de la izquierda muestra la versión almacenada en el repositorio local y el panel de la derecha muestra la versión almacenada en el área temporal. La diferencia entre las dos versiones se encuentra resaltada para facilitar su identificación.

El siguiente paso es confirmar los cambios en el repositorio local. Para ello, debo hacer click en el botón Commit que se encuentra en la ventana Pending Changes (Git) y luego debo hacer click en el botón OK de la ventana Commit.

commit

Ahora la ventana Branch Compare muestra información indicando que los repositorios remoto y local no se encuentran sincronizados.

branch_compare2

El paso final consiste en sincronizar los repositorios remoto y local enviando los cambios a GitHub. Para lograrlo, voy al menú principal y hago click en  Team -> Git -> Push para abrir el asistente “Push to Git” donde ingreso el URL del repositorio remoto, el user name y el password para completar la operación. Luego voy a GitHub para asegurarme que los cambios fueron transferidos.

updated_github

 


SQL Developer y la interfaz para trabajar con GIT: Interactuando con un repositorio GitHub Parte 1

En mi último post mostré como clonar un repositorio GitHub usando SQL Developer. En este post voy a mostrar como sincronizar los repositorios remoto (GitHub) y local (PC) una vez que remoto ha sido modificado.

En primer lugar voy a utilizar la funcionalidad existente en GitHub para crear el archivo sp_test_git.pls y luego voy a actualizar el repositorio. Se puede crear un nuevo archivo haciendo click en el ícono señalado con la flecha roja.

new_file

El contenido del archivo es un procedimiento PL/SQL que muestra un mensaje.

file_content

En este momento los repositorios remoto y local ya no se encuentran sincronizados. Lo primero que se debemos hacer antes de empezar a trabajar con un repositorio es asegurarnos de que tenemos la versión más reciente del mismo, de tal forma que incluya todos los cambios realizados por otros desarrolladores. Procedamos a sincronizar remoto y local.

En primer lugar debemos asegurarnos de que la ventana Versions se encuentre abierta. Vamos al menú principal y hacemos click en Team -> Versions.

versions

Luego debemos recorrer la estructura del repositorio local hasta llegar a la derivación máster y la seleccionamos. Ahora vamos al menú principal y hacemos click en Team -> Git -> Fetch para abrir el asistente “Fetch from Git” y seguimos las instrucciones que son similares a a las que utilizamos para clonar el repositorio. Cuando se realiza una operación Fetch sobre un repositorio, lo que realmente ocurre es que se guarda una copia de los cambios del repositorio remoto en una ubicación temporal (en el PC) de manera que no se modifica ninguna de las derivaciones en el repositorio local. En ese momento tenemos la opción para solamente comparar los cambios (Compare) o también podemos incorporar los cambios (Merge) en el repositorio local. Los archivos que han cambiado se muestran en la ventana Branch Compare que aparece cuando vamos al menú principal y hacemos click en Team -> Git -> Branch Compare.

branch_compare

En la ventana Branch Compare podemos hacer click con el botón derecho sobre sp_test_git.pls y elegir Compare para ver las diferencias entre la versión remota y local de sp_test_git.pls.

compare

La ventana del lado izquierdo muestra la versión remota del archivo y la ventana de la derecha muestra la versión local. En este caso la ventana de la derecha se encuentra vacía ya que el archivo es nuevo y no existe una copia previa en el repositorio local. Podemos incorporar los cambios al repositorio local en forma definitiva haciendo click con el botón derecho sobre sp_test_git.pls, eligiendo Merge y haciendo click sobre el botón “Ok”.

merge

Ahora podemos ir al directorio que contiene nuestro repositorio local y confirmar que sp_test_git.pls se encuentra ahí.

local_update

 


SQL Developer y la interfaz para trabajar con GIT: Clonando un repositorio GitHub

SQL Developer 4 provee una interfaz que nos permite interactuar con repositorios Git. En este post voy a mostrar una manera de clonar un repositorio almacenado en GitHub (Un servicio de hosting basado en la web para proyectos de desarrollo de software que utiliza el sistema de control de versiones Git).

Lo primero que debemos hacer es crear una cuenta en GitHub. Obviamente podemos ir al siguiente paso si es que ya contamos con una cuenta.

La cuenta en GitHub nos da acceso a repositorios públicos que podríamos clonar pero les recomiendo crear un repositorio propio para poder probar las diferentes funcionalidades que se incluyen en SQL Developer.

Una vez que la cuenta ha sido creada, debemos hacer click en el botón verde que dice “New Repository” que nos lleva a una página que luce así.

 

github_create_repo

 

Aquí debemos ingresar el nombre del repositorio que vamos a crear, decidir si el repositorio va a ser público (gratis) o privado (pagado) y hacer click en el check box. Finalmente hacemos click en el botón verde que dice “Create Repository” y eso nos lleva a la página principal de nuestro nuevo repositorio que debería ser similar a la siguiente imagen.

 

github_repo

 

Aquí hay que prestar atención a la flecha roja en la esquina inferior derecha. EL HTTPS clone URL es algo que vamos a necesitar cuando configuremos el acceso a GitHub en SQL Developer.

Ahora vamos a realizar la configuración de la conexión a GitHub en SQL Developer. En el menú principal hacemos click en Team –> Git –> Clone… para abrir el asistente “Clone from Git”. Aquí hacemos click en el botón que dice “Next” y que nos lleva a la pantalla para ingresar los detalles del repositorio que deseamos clonar.

 

remote_repo

 

Aquí debemos ingresar el nombre del repositorio que creamos, el HTTPS clone URL, el user name y password de nuestra cuenta GitHub. Luego hacemos click en el botón “Next” para tratar de establecer la conexión con el repositorio. Si la conexión fue exitosa, nos aparece la pantalla para elegir la derivación (branch) que deseamos clonar de lo contrario nos aparecerá algún mensaje de error.

 

remote_branch

 

Aquí solamente tenemos disponible la derivación master que se incluye por default cada vez que creamos un repositorio. Entonces hacemos click en el botón que dice “Next” y eso nos lleva a la pantalla donde debemos especificar el directorio en nuestra computadora que va a almacenar la copia local del repositorio Git.

 

destination

 

Ahora debemos especificar la ruta para almacenar el repositorio local y luego hacemos click en el botón “Next”. La última pantalla muestra un resumen de nuestra configuración. Aquí hacemos click en el botón “Finish” para completar el proceso.

Ahora la pregunta es ¿cómo sabemos si todo está funcionando correctamente? Si vamos a la ubicación que especificamos para almacenar nuestro repositorio local, deberíamos encontrar la misma estructura de carpetas y archivos que se muestran en la página principal de nuestro repositorio en GitHub.

 

local_repo

 

En otro post voy a mostrar la manera en que podemos hacer cambios en el repositorio local y la manera de sincronizar los cambios con el repositorio en GitHub.


¿Cómo habilitar el depurador PL/SQL de SQL Developer para trabajar con Oracle 12c?

SQL Developer posee un depurador de código PL / SQL que no necesita mayor configuración si se lo utiliza con Oracle 11g u otra versión previa. Normalmente necesitamos asegurarnos de que los siguientes pasos han sido ejecutados antes de intentar usar el depurador:

  1. Otorgar el privilegio DEBUG CONNECT SESSION al schema que contiene el código PL/SQL.
  2. Otorgar el privilegio de ejecución (EXECUTE) sobre el paquete DBMS_DEBUG_JDWP al schema que contienen el código PL/SQL.
  3. Verificar que tenemos el privilegio de ejecución (EXECUTE) sobre el código PL/SQL (paquete, procedimiento, función) que se desea depurar.
  4.  Verificar que el código PL/SQL se encuentra compilado en “modo debug” .

Si desean más información sobre los cuatro pasos que acabo de mencionar y cómo utilizar el depurador, pueden visitar el blog de Jeff Smith (PM de SQL Developer) que tiene una publicación sobre estos temas.

Ahora veamos lo que sucede cuando el código PL/SQL que deseamos depurar se encuentra en Oracle 12c. Los cuatro pasos que mencioné previamente todavía son necesarios pero ya no son suficientes. Miren el error que me apareció cuando intenté usar el depurador .

Executing PL/SQL: CALL DBMS_DEBUG_JDWP.CONNECT_TCP( ‘192.168.0.10’, ‘49428’ )
ORA-24247: network access denied by access control list (ACL)
ORA-06512: at “SYS.DBMS_DEBUG_JDWP”, line 68
ORA-06512: at line 1
Process exited.
Disconnecting from the database SCOTT – ORA12CPDB1

A partir de Oracle 12c , si deseamos usar un depurador de código PL/SQL como el que se incluye en SQL Developer o JDeveloper y que implementa el Java Debug Wire Protocol (JDWP), es necesario otorgar el privilegio de control de acceso (ACL) JDWP para permitir que la sesión de la base de datos se comunique con el depurador.

A continuación una manera de configurar el acceso de red para operaciones JDWP :

BEGIN
 DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE
 (
 host => '192.168.0.10',
 lower_port => null,
 upper_port => null,
 ace => xs$ace_type(privilege_list => xs$name_list('jdwp'),
 principal_name => 'scott',
 principal_type => xs_acl.ptype_db)
 );
END;

Host (donde se está ejecutando el depurador) puede puede ser un nombre de host, nombre de dominio, dirección IP o subred.

Principal_name en sección la entrada de control de acceso (ACE ) es el schema que contiene el código PL/SQL que se desea depurar.

Una vez que ejecutamos el bloque PL/SQL que configura el acceso de red para operaciones JDWP, el error desaparece y se puede empezar a utilizar el depurador como se muestra a continuación.

Connecting to the database SCOTT – ORA12CPDB1.
Executing PL/SQL: ALTER SESSION SET PLSQL_DEBUG=TRUE
Executing PL/SQL: CALL DBMS_DEBUG_JDWP.CONNECT_TCP( ‘192.168.0.10’, ‘49428’ )
Debugger accepted connection from database on port 49428.
Executing PL/SQL: CALL DBMS_DEBUG_JDWP.DISCONNECT()
Inside the Procedure
Process exited.
Disconnecting from the database SCOTT – ORA12CPDB1.
Debugger disconnected from database.

Espero que les sirva cuando sea tiempo de migrar a Oracle 12c .


Errores JDBC en SQL Developer 4

Traducción del post original publicado en Julio 14 del 2013.

El día de ayer instalé SQL Developer 4 en una máquina virtual que también contenía Oracle 11g R2 y SQL Developer 3.2.20. No tuve ningún problema durante la instalación; pero el siguiente mensaje de error empezó a aparecer en cuanto hice click en cualquiera de las opciones que requería una conexión a la base de datos.

sqldev4_jdbc_error

Revisando las preferencias de configuración que se encuentran en la sección Database/Advanced, encontré una opción que permite elegir entre el OCI Thick driver o el JDBC Thin driver (de forma implícita). Mi instalación inicial estaba configurada para utilizar el OCI Thick driver como se puede observar en la imagen de abajo.

sqldev4_oci_thick

Todo volvió a la normalidad una vez que desactivé el uso del OCI Thick driver. Ahora la pregunta era, por qué tenía configurada esa opción cuando la opción por defecto es  el JDBC Thin driver.

Después de unos minutos recordé que mi otra versión de SQL Developer (3.2.20) estaba utilizando el OCI Thick driver y que cada vez que uno ejecuta una nueva versión de SQL Developer por primera vez, aparece una ventana preguntando si deseamos copiar las preferencias que tenemos en la versión anterior (lo cual yo hice). Eso explica parte del problema.

Ahora necesito averiguar por qué el OCI Thick driver funciona sin problemas con la versión 3.2.20 y no funciona para nada con la versión 4. A lo mejor That Jeff Smith me puede dar más información al respecto.

Actualización 07/15/2013: Como lo dice Jeff en los comentarios del post en inglés, podemos solucionar el problema si descargamos una versión reciente de la librería ocijdbc11.dll (disponible en el instant client 11.2.0.3 por ejemplo) y la colocamos en el directorio /sqldeveloper/bin.