Problemas con parser de errores

Buenas!

Estamos laburando con el parser de mensajes de error de postgres y nos encontramos con un par de cosas raras.
El primer problema fue el delimitador de campo. El parser usa la variable “lc_messages” para ver el encoding de la base, y si es alguna de las “es” usa doble menor y doble mayor. El problema es que postgres no le da mucha bola a esta variable en algunos casos (algo de la instalación?). Acá va una cap de mi ubuntu:

stock_1_0=# SHOW lc_messages ;
 lc_messages 
-------------
 es_AR.UTF-8
(1 row)

stock_1_0=# select;
ERROR:  syntax error at or near ";"
LINE 1: select;

El arreglo chancho para esto es hacer un alter de la db en cuestión, de la variable “lc_messages”. Uno creería que cambiaría el idioma de los mensajes, pero no. Quizás seria mejor que se puedan setear los separadores? mas que nada para no reescribir todo el método para sacar esa parte.

El otro problema fue que queremos capturar también los errores de sintaxis (42601) lanzados por la función “consultar_fuente”, pero no pudimos. Buscando en el código vimos que el método “consultar” de la clase “toba_db”, no esta permitiendo el parseo de errores. Esto esta hecho así por alguna razón?

Saludos.

Hola Esteban,

te diria que revises el locale del sistema y lo compares con el que esta usando postgres, en gral dicha variable si afecta el idioma, el tema es que tengas disponible en el sistema el locale que especifica la misma.

Quizás seria mejor que se puedan setear los separadores? mas que nada para no reescribir todo el método para sacar esa parte.

Si estas haciendo una subclase para manejar errores especificos de postgres, podes cambiar el metodo que reasigna los delimitadores en base al locale, no tiene mucho sentido agregar un metodo para setear el delimitador desde afuera, cuando tenes acceso al codigo de la clase. Ademas, que queda raro que vos desde afuera sepas cual es el delimitador interno que se debe usar y no la clase que maneja eso.

Finalmente, que cambies los delimitadores por codigo no te va a hacer ningun favor, ya que vas a tener que estar especificandolos en toda instalacion.

El otro problema fue que queremos capturar también los errores de sintaxis (42601) lanzados por la función "consultar_fuente", pero no pudimos. Buscando en el código vimos que el método "consultar" de la clase "toba_db", no esta permitiendo el parseo de errores. Esto esta hecho así por alguna razón?

El tema es que no se si tiene sentido capturar los errores de sintaxis, ya que los mismos no dependen de los datos, aca no hablas de una PK, una FK o un indice que saltan, estamos hablando de algo que quedo mal hecho en desarrollo directamente o que quedo mal formado por no chequear correctamente los parametros.

Saludos

Hey Richard,

te diria que revises el locale del sistema y lo compares con el que esta usando postgres, en gral dicha variable si afecta el idioma, el tema es que tengas disponible en el sistema el locale que especifica la misma.

Ya lo tengo arreglado, solamente quería mostrar que usar esa variable no es la mejor manera de determinar el delimitador.

Si estas haciendo una subclase para manejar errores especificos de postgres, podes cambiar el metodo que reasigna los delimitadores en base al locale, no tiene mucho sentido agregar un metodo para setear el delimitador desde afuera, cuando tenes acceso al codigo de la clase. Ademas, que queda raro que vos desde afuera sepas cual es el delimitador interno que se debe usar y no la clase que maneja eso.

Finalmente, que cambies los delimitadores por codigo no te va a hacer ningun favor, ya que vas a tener que estar especificandolos en toda instalacion.

A mi me pareció raro tener que reescribir todo el método “parsear” en la clase heredada simplemente para poder asignar 2 variables, que aparte son de clase. Quedaría código duplicado sin sentido. Pero es de menor importancia, ya que se puede hacer.

Lo más complicado es la imposibilidad de capturar los state 42601, ya que el objetivo general del parseo de mensajes de error de la base de datos, creo yo, es generar un mensaje que el usuario pueda leer ocultando el lenguaje del motor.
Por otro lado entiendo que la propuesta de toba es la de recuperar info contextual mediante una conexión paralela y que precisamente acá no aplica, pero vuelvo al tema anterior, los errores de sintaxis son comunes (no solo por falta de parámetros) y seria interesante poder manejar todas las excepciones del mismo lugar.

Entiendo también, que no este en los planes que esto suceda, entonces pregunto: Cual es la razón por la que se especifico al método “consultar” de la clase “toba_db” que no use el parser? Es posible extender la clase para redefinir ese comportamiento?

Gracias!

Hola Esteban,

cierto, lo ideal seria tener una variable del motor que indicara explicitamente cual es el delimitador que usa, en dicho caso no habria chances de error… pero hasta donde se, no existe o al menos no tengo conocimiento, por lo que lc_messages parecio la mejor opcion.

A mi me pareció raro tener que reescribir todo el método "parsear" en la clase heredada simplemente para poder asignar 2 variables, que aparte son de clase. Quedaría código duplicado sin sentido. Pero es de menor importancia, ya que se puede hacer.

Es un punto, quizas hay que refactorizar esa parte para que sea mas granular y con solo hacer una redefinicion para anular la asignacion incorrecta alcance.

Entiendo que no te guste no poder asignar el delimitador desde afuera… pero pensa que si trabajaras con 2 o mas motores distintos, al momento de enviar a parsear el error tendrias que estar decidiendo segun el tipo de motor cual es el delimitador correcto a pasarle a las clases, o no hacer nada y dejar que use el declarado en el parser especifico. Esa clase de acoplamiento, no parece logica cuando existen objetos creados especificamente para manejar esas situaciones, si fuera un parser generico de erorres… seria otra cosa.

Lo más complicado es la imposibilidad de capturar los state 42601, ya que el objetivo general del parseo de mensajes de error de la base de datos, creo yo, es generar un mensaje que el usuario pueda leer ocultando el lenguaje del motor. Por otro lado entiendo que la propuesta de toba es la de recuperar info contextual mediante una conexión paralela y que precisamente acá no aplica, pero vuelvo al tema anterior, los errores de sintaxis son comunes (no solo por falta de parámetros) y seria interesante poder manejar todas las excepciones del mismo lugar.

Entiendo también, que no este en los planes que esto suceda, entonces pregunto: Cual es la razón por la que se especifico al método “consultar” de la clase “toba_db” que no use el parser? Es posible extender la clase para redefinir ese comportamiento?

Sigo insistiendo, un error de sintaxis no deberia pasar el testeo basico de la operacion, no es algo que este fuera de nuestras manos durante el desarrollo, como si lo puede ser que una secuencia haya quedado desactualizada en produccion debido a un mal manejo con la bd, son cuestiones fundamentalmente distintas.

No se si no sucedera, creo que es algo que requiere mas analisis tanto para un lado como para el otro… pero si sucede, ciertamente no va a ser por los errores de sintaxis, ese no es un buen argumento en lo absoluto. El porque se decidio que fuera asi, deberia consultarlo con la persona que lo hizo en su momento, quizas haya sido que a su criterio no era necesario o sino capaz tuvo algun inconveniente tecnico.

En cuanto tenga alguna novedad, te aviso.

Saludos