JSON Java Tomcat7

Desarrollando webservices JAX-RS que reciben JSON como parámetros de entrada y que entregan a su vez JSON, me encontré con la necesidad de parsear los JSON de entrada.


En anteriores servidores de aplicación y versiones anteriores de Java, utilicé Jackson, GSON y otros parseadores externos


Pero J2EE 7 proporciona una API JSON de forma nativa y no es necesario tener un "proveedor" externo.


Pero el API solo proporciona interfaces, sin implementación. Y depende cada servidor de aplicaciones la correcta implementación, en mi caso utilizo Tomcat 7 y parseando JSON recibía el siguiente error:

java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
        at java.lang.Thread.run(Thread.java:724)
Caused by: javax.json.JsonException: Provider org.glassfish.json.JsonProviderImp
l not found        at javax.json.spi.JsonProvider.provider(JsonProvider.java:97)
        at javax.json.Json.createArrayBuilder(Json.java:257)

...

Dicho error se solucionó con la siguiente configuración de Maven:

    javax
    javaee-api
    7.0
    provided

    javax.json
    javax.json-api
    1.0

    org.glassfish
    javax.json
    1.0
    runtime

Aquí dejo una función de ejemplo, que  parsea un token de Facebook y extrae el campo id:

public int idTokenFacebook ( String token ) throws IOException {
 Integer id=-1;
 String  aux;

 URL url = new URL("https://graph.facebook.com/me?access_token="+token);

 try (InputStream is = url.openStream();
 JsonReader rdr = Json.createReader(is)) {

  JsonObject obj = rdr.readObject();

  if ( obj.containsKey("id")) {
   aux = obj.getString("id");
   id = Integer.valueOf(aux);
  } else {
   id =0;
  }
  System.out.print("id: "+id);

  return id;
 }
}

Indices únicos de campos de gran tamaño

Cuando queremos que una clave no esté duplicada entre las filas de alguna de nuestras tablas, es sencillo hacerlo, creamos una clave única (unique key) y nuestro gestor de bbdd tendrá cuidado de que no ocurra la duplicidad.


Pero que ocurre cuando la clave que queremos que sea única, mide más de 3.000 caracteres. Pues tenemos un problema porque en Postgresql, el máximo permitido son 2.000 y pico.


Se nos podría ocurrir, dividir el campo en dos campos y montar el índice sobre dichos campos. Pero obtendremos el mismo error.


La solución sería hacer un índice calculado, que fuese el hash del campo. El problema es que al ser un campo de más de 3.000 puede que tengamos colisiones indeseadas o falsos positivos.


CREATE UNIQUE INDEX uk_tabla
  ON esquema.tabla
  USING btree
  (
   md5(campo_unico)
  );


Para tratar de minorar el problema, podemos hacer un índice con un hash de parte de la clave (caracteres del 1-1500), compuesto por otro hash, con la parte restante de la clave (caracteres del 1501 al 3000). Así podríamos dividir cuantas veces queramos la clave, segmentando el índice, para hacer más difícil la colisión del índice.




CREATE UNIQUE INDEX uk_tabla_campo_unico
  ON esquema.tabla
  USING btree
  (
   md5(substr(campo_unico::text, 1, 1500)),
   md5(substr(campo_unico::text, 1501, 3000))
  );




Y en mysql. En este gestor tenemos un problema, no podemos aplicar la solución directamente, porque no existen los "índices calculados".


Por tanto la única solución para simularlos, es crear los campos calculados en la propia tabla. Y serán rellenados a través de triggers.


alter table tabla add trozo1 varchar(1500);
alter table tabla add trozo2 varchar(1500);


DELIMITER //
CREATE TRIGGER `tabla_insert` BEFORE INSERT ON `tabla` FOR EACH ROW BEGIN
 set NEW.trozo1  = sha1( SUBSTRING(new.campo_unico,1,1500));
 set NEW.trozo2 = sha1( SUBSTRING(new.campo_unico,1501));
end//
DELIMITER ;


CREATE UNIQUE INDEX uk_tabla_campo_unico
ON tabla
( trozo1, trozo2 );


Resumiendo si tenemos el problema de indexar de forma única un campo excesivamente largo, en Postgres tenemos la inestimable ayuda de la potencia de los índices calculados.


Por contra en Mysql tendremos que cambiar la estructura de la tabla y crear triggers que mantenga la información actualizada, y por último crear el índice, lo cual es bastante más incómodo a la vez que tedioso en la programación.

Busqueda de Esquemas en Postgres por defecto

Si teneis una base de datos con varios esquemas, llega un momento en que es complicado encontrar una tabla y es farragoso tener que escribir el nombre del esquema delante de cada tabla para acceder al contenido.

Una solución es modificar el search_path del usuario con el que te conectas a la base de datos, por ejemplo del usuario user_connect, conectado como superusuario:

alter user "user_connect" set search_path to "$user",public,master,soccer;

Pero es mucho mejor indicar el camino de acceso a nivel de base de datos, en lugar de hacerlo a nivel de usuario.

alter database "league" set search_path to "$user",public,master,soccer;

De esta forma todos los usuarios que se conecten a esta base de datos, podrán encontrar las tablas de forma cómoda, en los esquemas public, master, soccer y en un esquema con su propio nombre de usuario con el que se ha conectado.

Exportar una instancia

Comando para exportar mi instancia amazon a una imagen que poder cargar en un HyperV:

ec2addixt i-0cd6fd4c -e Microsoft -b export-ami-crom -f vhd -d "export i-0cd6fd4c -e Microsoft -b export-ami-crom" -O ...AKIA... -W ...feuC... --region eu-west-1 -U http://ec2.amazonaws.com/


Error
Client.NotExportable: Only imported instances can be exported.

Resulta que amazon no deja exportar ninguna instancia.

Solo puedes exportarla si la importastes en primer lugar sobre una máquina EC2.

No me ha gustado nada saber que solo puedo exportar lo que yo importé primeramente. Por lo tanto todas las AMIS del market de Amazon son un callejón sin salida, así que ojo.

Bloque de comandos sin crear una función

Si necesitas hacer pruebas con un bloque de comandos de pgsql, sin tener que crear una función, esta es la forma:

do
$$declare
intervalo varchar;
fecha     timestamp;
begin
--fecha := ;
intervalo:= 1 || ' days';
fecha := current_timestamp + intervalo::interval;

insert into acumulado(usuario_id,f_fin,texto) values ( 1, fecha, 'texto'  );

end$$;

Consulta de Bloqueos en PostgreSql > 9.2 y como matar procesos

Para las versiones de Postgres 9.2 o superiores podéis crear una vista que facilitará la consulta de los procesos que actualmente tiene bloqueos en vuestro sistema:

CREATE OR REPLACE VIEW public.procesos_bloqueantes(
    blocking_pid,
    blocking_user,
    blocking_query,
    blocked_pid,
    blocked_user,
    blocked_query,
    age)
AS
  SELECT kl.pid AS blocking_pid,
         ka.usename AS blocking_user,
         ka.query AS blocking_query,
         bl.pid AS blocked_pid,
         a.usename AS blocked_user,
         a.query AS blocked_query,
         to_char(age(now(), a.query_start), 'HH24h:MIm:SSs' ::text) AS age
  FROM pg_locks bl
       JOIN pg_stat_activity a ON bl.pid = a.pid
       JOIN pg_locks kl ON bl.locktype = kl.locktype AND NOT bl.database IS
         DISTINCT
  FROM kl.database AND NOT bl.relation IS DISTINCT
  FROM kl.relation AND NOT bl.page IS DISTINCT
  FROM kl.page AND NOT bl.tuple IS DISTINCT
  FROM kl.tuple AND NOT bl.virtualxid IS DISTINCT
  FROM kl.virtualxid AND NOT bl.transactionid IS DISTINCT
  FROM kl.transactionid AND NOT bl.classid IS DISTINCT
  FROM kl.classid AND NOT bl.objid IS DISTINCT
  FROM kl.objid AND NOT bl.objsubid IS DISTINCT
  FROM kl.objsubid AND bl.pid <> kl.pid
       JOIN pg_stat_activity ka ON kl.pid = ka.pid
  WHERE kl.granted AND
        NOT bl.granted
  ORDER BY a.query_start;

Una vez localizados los procesos que están produciendo el bloqueo y que sentencia están ejecutando, podemos tomar la decisión de eliminarlos si llevan demasiado tiempo en ejecución y no nos importa perder él resultado de la acción que estaban ejecutando. El identificador de proceso a matar es el "blocking_id" de la vista:

select pg_cancel_backend ( blocking_pid );

Indices no utilizados en postgresql

 Consultar los índices de tu bbdd que no están siendo utilizados, para ahorrar espacio o replantearte sus campos:

SELECT
    schemaname || '.' || relname AS table,
    indexrelname AS index,
    pg_size_pretty(pg_relation_size(i.indexrelid)) AS index_size,
    idx_scan as index_scans
  FROM pg_stat_user_indexes ui
  JOIN pg_index i ON ui.indexrelid = i.indexrelid
  WHERE NOT indisunique AND idx_scan < 50 AND pg_relation_size(relid) > 5 * 8192
  ORDER BY pg_relation_size(i.indexrelid) / nullif(idx_scan, 0) DESC NULLS FIRST,
  pg_relation_size(i.indexrelid) DESC;