El instalador debería pasar la base de datos de negocio?
Me está fallando la instalacion al momento de crear las bases de datos.
PHP Warning: file_get_contents(…\instalador_gestion\3.0.0/proyectos/gestion/aplicacion/sql/estructura/tablas.sql): failed to open stream: No such file or directory in …\instalador_gestion\3.0.0\acciones\instalar\pasos\paso_instalar_bases.php on line 265
o hay que hacerlo por separado?
Emilio
P.D.
comenté la línea de la estructura y hubo problemas menores.
Ahora, cuando entro al toba_usuarios del proyecto no me acepta los mails. (te comenté el problema de los escapes).
Se te ocurre algo para hacer?
me surgen dos problemas al momento de “generar” el instalador.
El proyecto usa la tabla de usuarios del toba en una operación y cuando me genera el instalador, lo hace pasando el schema que tiene el toba en desarrollo.
Sale este error cuando se lo ejecuta:
SQLSTATE[3F000]: Invalid schema name: 7 ERROR: schema “desarrollo” does not exist LINE 1: UPDATE desarrollo.apex_usuario …
Por otro lado, planteado en el post anterior, las doble barras en los formatos.
Cuando se ejecuta el programa instalado sale:
js_form_2548_form.agregar_ef(new ef_editable(‘ef_form_2548_formemail’, ‘Email’, [false, false, false], false, ‘’, ‘/[A-Z0-9._%±]+@[A-Z0-9.-]+\\.[A-Z]{2,4}/i’), ‘email’);
Editando los metadatos compilados se “arregla el problema”.
Que tendría que modificar para no tener que estar tocando las cosas a mano?
el tema de la cuadruple barra se solucionó editando cada formulario en el toba editor de la 2.3.
con ello se grabó en la tabla una sola barra y pasa correctamente con el instalador.
en el proyecto toba_usuarios aparentemente queda algun problema aunque no me afecta.
Lo del schema se solucionó modificando cada datos_tabla para que use el schema default de la fuente. Luego se modifica solo ese archivo.
El instalador genera la base de negocios usando la estructura y los datos explicitados en el archivo proyecto.ini, si te fijas existe toda una seccion para la base de datos, en particular:
;Listado de archivos .sql a ejecutarse durante la creación de la estructura, el orden determina el orden de creación
estructura = sql/estructura.sql
;El manejador de negocios permite tener ventanas para la instalacion y migracion de los datos de negocio, indicar aqui el path
;manejador_negocio = php/extension_toba/toba_referencia_manejador_instalacion.php
;Indicar los diferentes set de datos que el usuario puede elegir para instalar
grupos_datos = demo
[grupo_demo]
nombre = "Datos de prueba"
archivos = sql/datos_basicos.sql
Ahi se definen varias cosas, que archivo se usa para generar la estructura, en este caso puntual que archivo contiene el grupo de datos minimos para la instalacion y cual es la clase que se va a usar para crear y manipular la base de negocios. Con todo eso podes definir tu propia forma de crear la base de datos.
Lo del instalador, pareciera ser que no tiene permisos de acceso al archivo o que no esta en esa ruta, quizas te falto algun directorio al especificar de donde se sacaba la estructura.
Claro, el tema es que el schema ‘desarrollo’ existe por convencion, en un entorno de produccion no se usa el mismo y por tanto toda SQL que haga referencia explicita al mismo va a fallar, lo que podrias hacer en dicho caso, es utilizar la conexion a la base de datos de Toba y ejecutar las SQL en esa conexion, en lugar de hacerlo con la conexion a la base de negocios.
Por otro lado, planteado en el post anterior, las doble barras en los formatos.
Cuando se ejecuta el programa instalado sale:
js_form_2548_form.agregar_ef(new ef_editable('ef_form_2548_formemail', 'Email', [false, false, false], false, '', '/[A-Z0-9._%+-]+@[A-Z0-9.-]+\\\\.[A-Z]{2,4}/i'), 'email');
Estoy rastreando el problema, aparentemente en algun momento se le agregaban las barras molestas esas, el tema es que no se hace durante el proceso de exportacion… asi que si el dato no lo trae ya incorporado desde la operacion de edicion, no hay forma que se agregue.
Lo bueno es que puedo replicarlo y por tanto buscar el origen, lo malo es que no quedan addslashes en lugares por donde pase la operacion :(.
1- lo de pasaje de la base de datos,
directamente lo comenté y la paso via backup del postgres.
no existían los archivos sql/estructura, etc.
2.- schema
varios Datos_tabla tenían seteado el schema desarrollo en lugar de dejar el default de la fuente.
esos fallaban.
Lo mismo en el metadato compilado que contiene la fuente hay que modificarlo a mano.
3.- lo de las
el problema se dá en producción, en entorno de desarrollo no me falló.
habia dos que supuse que podian ser, pero esta mañana “funcionó de otra forma” (parsear_archivo y preparar_js sinceramente no los depuré a ver si iban por ahi.) Lo que es seguro que si tiene dos \ en la base te quedan 4 en el js.
4.- El problema del schema anterior se dá con la conexion a toba_usuarios. En desarrollo está en un schema y en producción se lo manda a otro. Habría que ver alguna forma de identificarla y “traducirla” puesto que en general se pasa tambien esto.
Ok, misterio develado… si te funciono con el .backup mejor.
2.- schema
varios Datos_tabla tenían seteado el schema desarrollo en lugar de dejar el default de la fuente.
esos fallaban.
Lo mismo en el metadato compilado que contiene la fuente hay que modificarlo a mano.
Si, este es un tema de diseño.. el schema se guarda en el mismo DT y en gral el mismo no cambia entre desarrollo y produccion, salvo el de Toba y ahi es donde se arma el despiole, voy a agregar info a la documentacion sobre el tema y vere que se puede hacer para que se exporten con el schema default en lugar de uno puntual. Gracias por el aviso.
3.- lo de las \
el problema se dá en producción, en entorno de desarrollo no me falló.
habia dos que supuse que podian ser, pero esta mañana "funcionó de otra forma" (parsear_archivo y preparar_js sinceramente no los depuré a ver si iban por ahi.) Lo que es seguro que si tiene dos \ en la base te quedan 4 en el js.
El tema es como llega a PHP y se guarda en la BD, porque en definitiva eso impacta en la exportacion, al momento de enviar la ER a JS si se hace un addslashes para evitar que alguna barra sea tomada como caracter de escapado por PHP y la elimine al hacer el echo del string, de todas maneras… ahi no va como dato del EF, sino que va como codigo… igual voy a trazarlo para ver si esta enganchandose de una forma medio loca por ahi.
4.- El problema del schema anterior se dá con la conexion a toba_usuarios. En desarrollo está en un schema y en producción se lo manda a otro. Habría que ver alguna forma de identificarla y "traducirla" puesto que en general se pasa tambien esto.
Como te decia mas arriba, lo mas seguro en estos casos es trabajar con el default, ya que al pasar a produccion no hay logica que manipule los metadatos, de hecho es la idea… que no se los toque y se los use como vienen de desarrollo.
Lo del schema de la base de “usuarios” creería que sería mas piola ponerle en la fuente de datos un flag “es_base_toba” y al momento de publicarlo se la traduce igual que a la base de toba real.
Si no siempre habrá que “traducir” algo en los metadatos compilados. En mi caso me quedó solo la modificación de la fuente de datos. Con eso anduvo.
Retomo el tema de las doble barras en edit_expreg.
Hoy generé el instalador de un proyecto y cuando lo pasé a produccion me apareció la doble barra en el formulario del toba_usuarios, no en los del proyecto.
Se genera por lados diferentes?
En la base de desarrollo están los dos (varios) con una sola barra.
en respuesta a tu pregunta… no y si, osea… el proyecto toba_usuarios lo generamos nosotros, el instalador meramente copia el contenido del mismo.
Por tanto si el proyecto viajo con la doble “\”, lo cual es posible dado que muchos aun tenemos desactivado el standard_conforming_string en postgres 9.x,
se va a copiar literalmente dentro el instalador.
El problema viene dado porque la funcion quote, se comporta de manera diferente de acuerdo a la configuracion de postgres.
Evidentemente tenemos configuraciones cruzadas, por el momento.