[Javier Ader]

Buenas. A partir de este thread https://www.libertya.org/comunidad/foro-libertya/8-desarrolladores/1325#1325 se me planteo usar vistas dentro de las pestañas y de paso desarrollar un ejemplo como componente.
Mi idea es que la ventana Tarifas no solo muestre los productos asociados a una versión de lista, si no también en otra pestaña la lista de aquellos productos que NO están asociados con una versión determinada [no se si esto será de utilidad en general, a mi me gustaba la idea ya que por ej, después de un importación de productos simple estos no tienen asociado un precio]. Adicionalmente agregarle un botón a esta pestaña para que se pueda agregar un precio desde ahí mismo (la idea es que apareciese un dialogo solicitando los 3 precios, y al dar aceptar se crease un entrada en la tabla correspondiente via un callout asociado al botón).

Bueno, el tema es que
1) todo las columnas que están asociadas a una vista son “no actualizables” si o si. Esto tiene sentido en general, pero en el caso de un botón no permite que se dispare. A esto último le veo utilidad potencial en general.
2) la vista era necesariamente poco eficiente por dos razones: la primera es que postgress no creo que pueda hacer optimizaciones fuera de la vista (por ej, select una_vista where ad_client_id = XXX; el ad_client_id = xxx no creo que se usado para optimizar evaluación interna de la vista; esto es, la vista genera una entrada PARA todos los clientes; y despues el select filtra); y después por que tanto libertya como postgres no soportan vistas con parámetros. Con respecto a esto tengo una idea que voy a plantear en otro thread como posible extensión; básicamente permitir “vistas” libertya basadas en funciones postgres que retornan registros o permitir definir definir una vista libertya como una sentencia select arbitraria pero con posibles “parametros” (por ej @AD_Client_ID). En cualquiera de los dos casos se logran optimizaciones a nivel sql (en el segundo además, se pueden crear “vistas” a nivel de metadatos sin necesidad de crearla a nivel de postgress). Ok igual excede a lo que iba…
3) la instalación del componente fallo en el preinstall.sql; esta vez no por los comentarios (los saque y seguia el error); creo que esta vez es porque utilizo LF como final de linea. Este LF bajo mi instalación parece que no es ni siquiera considerado por postgres como un espacio en blanco, asi que este preinstall http://www.eltita.com.ar/libertya/psp01/preinstall-orig.sql me tiraba un error de sintaxis “cerca de SELECTAS“; lo solucione cambiando el LF por un espacio en blanco. Esto al parecer no pasa cuando se generan tablas simplemente porque la sintaxis del “create table” no requiere espacios para que sea sintácticamente correcta.
4) la instalación del componente, por alguna razón me genero los nombres de los campos con acentos mal. Acá esta el screenshot
[img]http://www.eltita.com.ar/libertya/psp01/error-nombres-campos-libertya-comp.JPG[/img]
Ni idea porque; en el componente de Juguetes que hice antes creo que pasaba esto.

Bueno, dejo la definición de la vista (dicho sea de paso, tal vez lo que haga con created, createdby, updated, updatedby, no es muy correcto, pero después de todo, esas filas no existen asi que no fueron creadas por nadie obviamente)

CREATE OR REPLACE VIEW libertya.v_product_not_in_plv AS
SELECT plv.ad_client_id, plv.ad_org_id, plv.m_pricelist_version_id, p.m_product_id,
NULL::timestamp without time zone AS created, 0 AS createdby,
NULL::timestamp without time zone AS updated, 0 AS updatedby
FROM ( SELECT m_pricelist_version.m_pricelist_version_id, m_pricelist_version.ad_client_id, m_pricelist_version.ad_org_id
FROM libertya.m_pricelist_version) plv,
( SELECT m_product.m_product_id, m_product.ad_client_id
FROM libertya.m_product
WHERE m_product.producttype = 'I'::bpchar OR m_product.producttype = 'R'::bpchar) p
WHERE plv.ad_client_id = p.ad_client_id AND NOT (EXISTS ( SELECT 1
FROM libertya.m_productprice pp
WHERE pp.m_product_id = p.m_product_id AND pp.m_pricelist_version_id = plv.m_pricelist_version_id));

ALTER TABLE libertya.v_product_not_in_plv OWNER TO libertya;

El componente lo pueden bajar acá http://www.eltita.com.ar/libertya/psp01/PSP1.0.zip (los archivos por separado http://www.eltita.com.ar/libertya/psp01/); un screenshot de como se ve la pestaña (sacada usando la base de desarrollo, en la de instalación estan los problemas de los acentos)
[img]http://www.eltita.com.ar/libertya/psp01/psp01.JPG[/img]

[Federico Cristina]

Javier,

Respecto del punto 4, por lo que veo estas trabajando bajo Windows… ¿cómo generaste el XML? ¿cómo accediste a la aplicación?. Esto incide bastante en el tema, y también nos pasó en las pruebas que hicimos previas al release.

Tanto es así, que para los usuarios que necesitaban actualizar de la 9.10 a 10.03 fue necesario incluirle una modificación en el inicio de Libertya (-Dfile.encoding=UTF- para los archivos libertya.sh y libertya.bat (dado que la instalación de componentes debe hacerse únicamente de manera local), a fin de garantizar la correcta codificación en la lectura de los archivos.

El punto 3 posiblemente también tenga algún punto de contacto con lo anterior comentado.

EDIT: obviamente que en el próximo release ya estarán actualizados estos archivos con dicha modificación.

Saludos,
Federico

[Javier Ader]

y… ya no sabría decirte con certeza jaja. Te digo mi configuración:
-cliente instalado por el instalador automático para la localización AR (bajo XP)
-base de datos de desarrollo creada por el instalador anterior
-base de datos de instalación creadas por mi usando los .sql que en el directorio data del instalación anterior y el sql para instalar sqlj. La base de datos la cree desde pgadmin especificándole enncoding UTF8 (que supongo que es el encoding default para todo; aunque probablemente NO para el enconding de las conexiones, aunque no creo que venga por ahi).
-use el mismo cliente tanto para la exportación como la instalación del componente (obviamente accediendo a distintas bases de datos)
-siempre acceso seleccionando el lenguaje AR

El tema es que cuando instale el componente de Juguetes hice exactamente lo mismo (bah, creo) y los nombres de los campos (y asumo que todo lo que sea strings) fue generado en UTF8 y también importado usando el mismo encoding (por ej, el campo “Organización” en la ventana de juguetes aparecía bien en las dos bases de datos). Ahora, mirando el install.xml de este componente (PSP01) esta claramente en UTF8 (e.d, la exportación es correcta; busca dentro de este archivo por ej “Organización”); así que el tema debe venir por la importación. Bien, porque la importación de Juguetes anduvo bien con respecto a UTF8, pero la importación del actual componente no, es medio raro; las únicas diferencias son básicamente que uno crea una vista sql, mientras que el otro una tabla; pero a nivel de metadatos son similares, por ej en las inserciones en AD_Field_trl los dos tiene “Organización” en correcto UTF8.
Lo unico que se ocurre para este comportamiento cuasi-aleatorio es: las librerías de Java de acceso archivos de texto, si no se le especifica cual es el encoding del archivo (o cual es el encodig por defecto), hace lo que muchos editores de texto: llevan a cabo un algoritmo que no es 100% seguro para “estimar” cual es el encoding (por ej, si comienza con los bytes “BOM”, obviamente es UTF8; si no, leen los primeros caracteres y si encuentra uno que NO puede pertenecer a UTF8, asumen que es otro enconding, etc etc; dicho sea de paso, no existe un algoritmo 100% seguro para esto). Obviamente, si este estimación falla va todo mal…
Estoy casi seguro que si agarro el install.xml y le pongo un “BOM” adelante (por ej, con notepad++) y vuelvo a instalar el componente, va a andar bien, ya que java se va a dar cuenta que está en UTF8 (pero bueno… tengo que crear ooooootra base de datos). Después lo testeo y me saco la duda.

En cuanto al tema del preinstall.sql, el tema creo que viene por otro lado y aca creo que si depende de postgress más que de libertya (aunque seguro que desde libertya se puede subsanar); en particular de donde esta instalado el servidor. Si vos miras el preinstall.sql de Juguetes y el de este componente vas a ver que lo unico que cambia es que una crea una tabla y el otro una vista. Los dos archivos usan a veces LF y otras CR,LF como separador de lineas (por lo que vi, usan LF para separarar las columnas y cosas por el estilo y CRLF para separar sentencias CREATE completas). Asi por ej, el create de Juguetes comienza (viendolo en notepad++ mostrando los finales de linea)

Code:

CREATE TABLE M_Juguetes([LF]
[LF]
m_juguetes_id integer NOT NULL, etc etc etc

y el de la vista como

Code:

CREATE VIEW v_product_not_in_plv AS[LF]
SELECT plv.ad_client_id

En los casos usa LF como separador, pero en el último, si un elimina el LF (o no lo considera como un separador que creo que es lo que pasa cuando postgress esta instalado bajo Windows) se cae en un error sintáctico ya que AS queda pegado al SELECT (e.d “CREATE VIEW v_product_not_in_plv ASSELECT”). Pero en el caso de la tabla queda “CREATE TABLE M_Juguetes(m_juguetes_id integer NOT NULL” todo junto, lo cual NO es un error sintáctico ( el “(” justo despuesde M_Juguetes sirve como separador, de igual manera que las comas sirven después como separador de columnas dentro del create). E.d, es algo que que debe pasar solo cuando se crea una vista y solo cuando el server está bajo Windows. Creo que esto no es un error relativo a UFT8 (UTF8 incluye tanto a LF como a CR), si no que se están generando algunas separaciones con LF y otras con CRLF. Yo lo solucione sacando el LF y poniendo un espacio en su lugar, como esta en dentro del PSP01.zip (obviamente me quedo un create view larguisimo de una sola linea); seguro que también hubiese andado si reemplazaba el LF por CRLF (lo que no se es si esto ultimo hubiese traído problemas si lo hubiese instalado en servidor corriendo bajo Linux….)

[Javier Ader]

bueno, ninguna de mis posibles soluciones andan. Creé una nueva base de datos y genere un preinstall.sql con CRLF separando al SELECT del AS; mismo error (“error de sintaxis cerca de SELECTAS”); asi que me parece que el unico separador que le gusta a postgres al menos bajo windows es es el espacio, quizá también tab (ok, no mire el código que le pasa estas sentencias a postgres, pero me da la sensación de que no va por ahi el tema).
Cambie el LF por espacio como antes y pase a probar tema del BOM. Modifique con notepad++ para que me agregue el BOM en el install.xml; instale y ahora me tiro el error en el install
====insertando metadatos de instalación===
Error al realizar la instalación: Content is not allowed in prolog.
mirando un poco en google (por ej http://forums.sun.com/thread.jspa?messageID=9436622#9436622) a las librerías de java tampoco les gusta el BOM…
En cualquier caso es raro que librerías hechas para manejar xml no se den cuenta que el archivo esta en UTF8 (aún mas teniendo el atributo encodig=”UTF-8″ en el tag xml).
Ahora me falta probar ejecutarlo con el flag -Dfile.encoding=UTF-8; ahi seguro que anda.

AGREGO: ahi lo probe con el flag e instalo correctamente el PSP01.zip que linkie más arriba… ahora me doy cuenta a que iba tu pregunta “Como lo ejecutaste?”. El tema de por qué con los juguetes anduvo, es porque muy probablemente lo haya corrido desde eclipse y eclipse setea el -Dfile.encoding=UTF-8, al menos en modo debug; no me habia imaginado está diferencia. Lo unico es que con o sin flag parece que el exportador si lo crea en UTF8 (el install.xml que use era el generado ejecutando el cliente “normal”).
Ahora, lo de LF o CRLF o lo que sea que pase con las vistas, creo que sigue estando.

[Autor]

Entradas