Hola, este es mi primer mensaje a la lista, mucho gusto con todos. Estoy tratando de instalar alba con postgres, el alba es el ultimo que acabo de hacer checkout del svn, entro al instalador y me tope con lo siguiente: Cuando pruebo la conexión, aparece como que está tomando el username como base de datos, por lo que en el paso 3 modifique el string de conexion e inclui dbname=$db entre los parametros, la conexion se pudo realizar, pero la base debe estar creada con anticipacion. Luego en el siguiente paso, aparecio muchas veces el mismo error, y segun veo en el ver_log.php ningun query se ejecutó. Para motivos de prueba alguien me puede pasar su dump al menos de la estructura y/o datos de ejemplo de postgres, le agradezco mucho. Saludos, Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
El Monday 07 July 2008 14:09:42 Carlos Villavicencio escribió:
Hola, este es mi primer mensaje a la lista, mucho gusto con todos.
Estoy tratando de instalar alba con postgres, el alba es el ultimo que acabo de hacer checkout del svn, entro al instalador y me tope con lo siguiente:
Cuando pruebo la conexión, aparece como que está tomando el username como base de datos, por lo que en el paso 3 modifique el string de conexion e inclui dbname=$db entre los parametros, la conexion se pudo realizar, pero la base debe estar creada con anticipacion.
Aquí el problema que hay y en función de lo que has escrito encuentro es que si el usuario de postgres solo tiene permiso para acceder a una base previamente creada no puede instalarlo, ya que nunca se podra conectar. Lo que hay que arreglar en codigo es la posibilidad que puedas usar un base previamente creada para la que tenes permisos. Ahora contesto tambien tu ticket en trac para que alguien pueda trabajar en eso. http://alba.pressenter.com.ar/cgi-bin/trac.cgi/ticket/280
Luego en el siguiente paso, aparecio muchas veces el mismo error, y segun veo en el ver_log.php ningun query se ejecutó.
Para motivos de prueba alguien me puede pasar su dump al menos de la estructura y/o datos de ejemplo de postgres, le agradezco mucho.
La estructura la crear durante la instalación ya que depende de la base de datos que uses mysql o postgres. También leo en el trac que
2. En el archivo funciones.php en la parte de postgres, debo comentar el BEGIN (y por ende el COMMIT y ROLLBACK), ya que los drop table a tablas que no existen ocasionan error y todo el resto de queries no se ejecutan.
Deberiamos pensar como podriamos hacer para que podamos hacer que funcione. O sea poder validar si hubo algún error pero al mismo tiempo que no tire error por los drop table. -- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
Gracias por las respuestas. Tal vez DROP TABLE *IF EXISTS*, no se si se pueda hacer eso en postgres como en mysql. Saludos, Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558 2008/7/8 josx <[email protected]>:
El Monday 07 July 2008 14:09:42 Carlos Villavicencio escribió:
Hola, este es mi primer mensaje a la lista, mucho gusto con todos.
Estoy tratando de instalar alba con postgres, el alba es el ultimo que acabo de hacer checkout del svn, entro al instalador y me tope con lo siguiente:
Cuando pruebo la conexión, aparece como que está tomando el username como base de datos, por lo que en el paso 3 modifique el string de conexion e inclui dbname=$db entre los parametros, la conexion se pudo realizar, pero la base debe estar creada con anticipacion.
Aquí el problema que hay y en función de lo que has escrito encuentro es que si el usuario de postgres solo tiene permiso para acceder a una base previamente creada no puede instalarlo, ya que nunca se podra conectar.
Lo que hay que arreglar en codigo es la posibilidad que puedas usar un base previamente creada para la que tenes permisos. Ahora contesto tambien tu ticket en trac para que alguien pueda trabajar en eso.
http://alba.pressenter.com.ar/cgi-bin/trac.cgi/ticket/280
Luego en el siguiente paso, aparecio muchas veces el mismo error, y segun veo en el ver_log.php ningun query se ejecutó.
Para motivos de prueba alguien me puede pasar su dump al menos de la estructura y/o datos de ejemplo de postgres, le agradezco mucho.
La estructura la crear durante la instalación ya que depende de la base de datos que uses mysql o postgres.
También leo en el trac que
2. En el archivo funciones.php en la parte de postgres, debo comentar el BEGIN (y por ende el COMMIT y ROLLBACK), ya que los drop table a tablas que no existen ocasionan error y todo el resto de queries no se ejecutan.
Deberiamos pensar como podriamos hacer para que podamos hacer que funcione. O sea poder validar si hubo algún error pero al mismo tiempo que no tire error por los drop table.
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
_______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
El Tuesday 08 July 2008 12:29:52 Carlos Villavicencio escribió:
Gracias por las respuestas.
Tal vez DROP TABLE *IF EXISTS*, no se si se pueda hacer eso en postgres como en mysql.
Habría que probar. ¿Podes hacer lo de encontrar algo similar en Postgres?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
Hola... no hay manera de hacerlo en postgres, no hay if exists. Pero al ser un instalador, no le veo la necesidad de hacerlo como TRANSACción, sólo es mi apreciación personal. Otro dato interesante que encontré fue que al instalar los datos de ejemplo, los secuenciales no se incrementan, en mysql eso es automatico, pero en postgres es tedioso ya que se lo hace manual. Saludos, Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558 2008/7/8 josx <[email protected]>:
El Tuesday 08 July 2008 12:29:52 Carlos Villavicencio escribió:
Gracias por las respuestas.
Tal vez DROP TABLE *IF EXISTS*, no se si se pueda hacer eso en postgres como en mysql.
Habría que probar. ¿Podes hacer lo de encontrar algo similar en Postgres?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
_______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
El Tuesday 08 July 2008 13:14:49 Carlos Villavicencio escribió:
Hola... no hay manera de hacerlo en postgres, no hay if exists.
Ok
Pero al ser un instalador, no le veo la necesidad de hacerlo como TRANSACción, sólo es mi apreciación personal.
Yo sinceramente creo que si debemos saber si hubo algun problema en la creación de las bases o en la inserción de los datos. Voy a ver como podemos arreglar esto.
Otro dato interesante que encontré fue que al instalar los datos de ejemplo, los secuenciales no se incrementan, en mysql eso es automatico, pero en postgres es tedioso ya que se lo hace manual.
Gracias por el dato, ya que no tenemos muchas pruebas hechas con postgres. ¿Como podria arreglarse? Otra pregunta: ¿Qué versión de postgres estas usando?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
Hola, yo estoy rtratando tambien con postgres-8.3.3 y tengo un problema de localizacion tengo este error: Los archivos de este cluster ser�n de propiedad del usuario �postgres�. Este usuario tambi�n debe ser quien ejecute el proceso servidor. El cluster ser� inicializado con las configuraciones locales COLLATE: C CTYPE: es_EC MESSAGES: es_EC MONETARY: es_EC NUMERIC: es_EC TIME: es_EC initdb: codificaciones no coinciden La codificaci�n que seleccion� (UTF8) y la codificaci�n de la configuraci local elegida (LATIN1) no coinciden. Esto llevar�a a comportamientos err�ticos en ciertas funciones de procesamiento de cadenas de caracteres. Ejecute initdb nuevamente y no especifique una codificaci�n, o bien especifique una combinaci�n adecuada. El día 8 de julio de 2008 22:43, josx <[email protected]> escribió:
El Tuesday 08 July 2008 13:14:49 Carlos Villavicencio escribió:
Hola... no hay manera de hacerlo en postgres, no hay if exists.
Ok
Pero al ser un instalador, no le veo la necesidad de hacerlo como TRANSACción, sólo es mi apreciación personal.
Yo sinceramente creo que si debemos saber si hubo algun problema en la creación de las bases o en la inserción de los datos. Voy a ver como podemos arreglar esto.
Otro dato interesante que encontré fue que al instalar los datos de ejemplo, los secuenciales no se incrementan, en mysql eso es automatico, pero en postgres es tedioso ya que se lo hace manual.
Gracias por el dato, ya que no tenemos muchas pruebas hechas con postgres. ¿Como podria arreglarse?
Otra pregunta: ¿Qué versión de postgres estas usando?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
_______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
-- [b]Siempre existe una razon mas para amar tu Libertad... Ama tu GNU/Linux...[/b]
YO cuando cree la base desde el phpPgAdmin se creo por default en LATIN1, luego el instalador de alba no me presento problemas para crear las tablas. Saludos, Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558 Guayaquil - Ecuador 2008/7/9 Ovnicraft <[email protected]>:
Hola, yo estoy rtratando tambien con postgres-8.3.3 y tengo un problema de localizacion tengo este error:
Los archivos de este cluster ser�n de propiedad del usuario �postgres�. Este usuario tambi�n debe ser quien ejecute el proceso servidor. El cluster ser� inicializado con las configuraciones locales COLLATE: C CTYPE: es_EC MESSAGES: es_EC MONETARY: es_EC NUMERIC: es_EC TIME: es_EC initdb: codificaciones no coinciden La codificaci�n que seleccion� (UTF8) y la codificaci�n de la configuraci local elegida (LATIN1) no coinciden. Esto llevar�a a comportamientos err�ticos en ciertas funciones de procesamiento de cadenas de caracteres. Ejecute initdb nuevamente y no especifique una codificaci�n, o bien especifique una combinaci�n adecuada.
El día 8 de julio de 2008 22:43, josx <[email protected]> escribió:
El Tuesday 08 July 2008 13:14:49 Carlos Villavicencio escribió:
Hola... no hay manera de hacerlo en postgres, no hay if exists.
Ok
Pero al ser un instalador, no le veo la necesidad de hacerlo como TRANSACción, sólo es mi apreciación personal.
Yo sinceramente creo que si debemos saber si hubo algun problema en la creación de las bases o en la inserción de los datos. Voy a ver como podemos arreglar esto.
Otro dato interesante que encontré fue que al instalar los datos de ejemplo, los secuenciales no se incrementan, en mysql eso es automatico, pero en postgres es tedioso ya que se lo hace manual.
Gracias por el dato, ya que no tenemos muchas pruebas hechas con postgres. ¿Como podria arreglarse?
Otra pregunta: ¿Qué versión de postgres estas usando?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
_______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
-- [b]Siempre existe una razon mas para amar tu Libertad... Ama tu GNU/Linux...[/b] _______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
Estoy usando PostgreSQL 8.1.9 (se incluye en el linux CentOS 5.1) Me parece buena idea de saber que error sucedió. otra cosa que se me ocurre es quitarle los DROP TABLE ya que si es instalación, no deberían existir las tablas, o esas DROP TABLES (todas juntas) hacerlas en una transacción y en otra los CREATE TABLE. y en otra los datos de ejemplo. Para el problema de la secuencia, encontré una solución un tanto practica y que habría que probar... Encontre un tutorial corto y completo que explica las secuencias ( http://www.truesoftware.net/gevik/2008/06/synchronizing-sequence-values-upon...) , en resumen: - El campo ID no debe ser Integer sino Serial - automaticamente se crea un Predeterminado:: nextval('customer_customer_id_seq'::regclass) - en realidad lo hace integer a final de todo. pero ingresa el campo predeterminado que les expliqué. - Los inserts deberán hacerse sin el campo ID (Ejemplo: *INSERT INTO pais (nombre_largo, nombre_corto, orden) VALUES ('Argentina', 'ARG', 10); * ) - Si se hace el insert con el campo ID entonces no se toma en cuenta el auto secuencial Hice pruebas con la tabla pais, sólo cambie el valor predeterminado con el valor:: *nextval('pais_seq'::regclass)* en el phpPgAdmin y todo parece estar bien siempre que las secuencias esten en orden. Puede que sea una solucion a todo esto. 2008/7/8 josx <[email protected]>:
El Tuesday 08 July 2008 13:14:49 Carlos Villavicencio escribió:
Hola... no hay manera de hacerlo en postgres, no hay if exists.
Ok
Pero al ser un instalador, no le veo la necesidad de hacerlo como TRANSACción, sólo es mi apreciación personal.
Yo sinceramente creo que si debemos saber si hubo algun problema en la creación de las bases o en la inserción de los datos. Voy a ver como podemos arreglar esto.
Otro dato interesante que encontré fue que al instalar los datos de ejemplo, los secuenciales no se incrementan, en mysql eso es automatico, pero en postgres es tedioso ya que se lo hace manual.
Gracias por el dato, ya que no tenemos muchas pruebas hechas con postgres. ¿Como podria arreglarse?
Otra pregunta: ¿Qué versión de postgres estas usando?
Saludos,
Ing. Carlos Antonio Villavicencio M. Tel: (04) 2270318 - (09) 8067558
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
_______________________________________________ Alba-usuario mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/alba-usuario
El Wednesday 09 July 2008 14:55:49 Carlos Villavicencio escribió:
Estoy usando PostgreSQL 8.1.9 (se incluye en el linux CentOS 5.1)
Me parece buena idea de saber que error sucedió. otra cosa que se me ocurre es quitarle los DROP TABLE ya que si es instalación, no deberían existir las tablas, o esas DROP TABLES (todas juntas) hacerlas en una transacción y en otra los CREATE TABLE. y en otra los datos de ejemplo.
Estoy arreglando el código del instalador. Y saque los DROP TABLES directamente desde el código, hasta tanto no lo podamos generar así desde el PROPEL.
Para el problema de la secuencia, encontré una solución un tanto practica y que habría que probar... Encontre un tutorial corto y completo que explica las secuencias ( http://www.truesoftware.net/gevik/2008/06/synchronizing-sequence-values-upo n-manual-insert/) , en resumen:
- El campo ID no debe ser Integer sino Serial - automaticamente se crea un Predeterminado:: nextval('customer_customer_id_seq'::regclass) - en realidad lo hace integer a final de todo. pero ingresa el campo predeterminado que les expliqué. - Los inserts deberán hacerse sin el campo ID (Ejemplo: *INSERT INTO pais (nombre_largo, nombre_corto, orden) VALUES ('Argentina', 'ARG', 10); * ) - Si se hace el insert con el campo ID entonces no se toma en cuenta el auto secuencial
Hice pruebas con la tabla pais, sólo cambie el valor predeterminado con el valor:: *nextval('pais_seq'::regclass)* en el phpPgAdmin y todo parece estar bien siempre que las secuencias esten en orden.
Puede que sea una solucion a todo esto.
Ya me he dado cuento cual es el problema. Las secuencias funcionan bien, el problema es que los inserts están hechos completando en campo ID, por lo tanto no actualiza la secuencia. Debe encontrar alguna forma de actualizar las secuencias para que comience en el id correcto, de lo contrario hay que agregar los insert que se hacen al comienzo como un fixture de symfony. Estoy viendo cual es la mejor solucion.
Aquí el cambio para mejorar el instalador con las propuestas de correción de errores que enuncio Carlos. Si pueden prueben y comentenden si aún hay algún problema. http://alba.pressenter.com.ar/cgi-bin/trac.cgi/changeset/5735 El Thursday 10 July 2008 22:33:07 josx escribió:
El Wednesday 09 July 2008 14:55:49 Carlos Villavicencio escribió:
Estoy usando PostgreSQL 8.1.9 (se incluye en el linux CentOS 5.1)
Me parece buena idea de saber que error sucedió. otra cosa que se me ocurre es quitarle los DROP TABLE ya que si es instalación, no deberían existir las tablas, o esas DROP TABLES (todas juntas) hacerlas en una transacción y en otra los CREATE TABLE. y en otra los datos de ejemplo.
Estoy arreglando el código del instalador. Y saque los DROP TABLES directamente desde el código, hasta tanto no lo podamos generar así desde el PROPEL.
Para el problema de la secuencia, encontré una solución un tanto practica y que habría que probar... Encontre un tutorial corto y completo que explica las secuencias ( http://www.truesoftware.net/gevik/2008/06/synchronizing-sequence-values-u po n-manual-insert/) , en resumen:
- El campo ID no debe ser Integer sino Serial - automaticamente se crea un Predeterminado:: nextval('customer_customer_id_seq'::regclass) - en realidad lo hace integer a final de todo. pero ingresa el campo predeterminado que les expliqué. - Los inserts deberán hacerse sin el campo ID (Ejemplo: *INSERT INTO pais (nombre_largo, nombre_corto, orden) VALUES ('Argentina', 'ARG', 10); * ) - Si se hace el insert con el campo ID entonces no se toma en cuenta el auto secuencial
Hice pruebas con la tabla pais, sólo cambie el valor predeterminado con el valor:: *nextval('pais_seq'::regclass)* en el phpPgAdmin y todo parece estar bien siempre que las secuencias esten en orden.
Puede que sea una solucion a todo esto.
Ya me he dado cuento cual es el problema. Las secuencias funcionan bien, el problema es que los inserts están hechos completando en campo ID, por lo tanto no actualiza la secuencia. Debe encontrar alguna forma de actualizar las secuencias para que comience en el id correcto, de lo contrario hay que agregar los insert que se hacen al comienzo como un fixture de symfony. Estoy viendo cual es la mejor solucion.
-- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
El Tuesday 08 July 2008 12:41:01 josx escribió:
Tal vez DROP TABLE *IF EXISTS*, no se si se pueda hacer eso en postgres como en mysql.
Habría que probar. ¿Podes hacer lo de encontrar algo similar en Postgres?
ya lo encontre existe al menos en 8.2.9 el if exist http://www.postgresql.org/docs/8.2/interactive/sql-droptable.html Igualmente tengo que ver como me las arreglo para que propel (ORM que usa symfony evite o ponga los if exists) ¿alguna idea? -- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
El Monday 07 July 2008 14:09:42 Carlos Villavicencio escribió:
Cuando pruebo la conexión, aparece como que está tomando el username como base de datos, por lo que en el paso 3 modifique el string de conexion e inclui dbname=$db entre los parametros, la conexion se pudo realizar, pero la base debe estar creada con anticipacion.
Luego de leer algo de la documentación de Postgres me doy cuenta que si uno se conecto sin indicar base de datos asume como default una base de datos igual al nombre del usuario que se esta conectando. -- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
El Thursday 10 July 2008 12:41:39 josx escribió:
El Monday 07 July 2008 14:09:42 Carlos Villavicencio escribió:
Cuando pruebo la conexión, aparece como que está tomando el username como base de datos, por lo que en el paso 3 modifique el string de conexion e inclui dbname=$db entre los parametros, la conexion se pudo realizar, pero la base debe estar creada con anticipacion.
Luego de leer algo de la documentación de Postgres me doy cuenta que si uno se conecto sin indicar base de datos asume como default una base de datos igual al nombre del usuario que se esta conectando.
Me olvidaba de la referencia: http://www.postgresql.org/docs/8.2/static/libpq-connect.html -- Di Biase José Luis Blog --> [http://www.joseluisdibiase.com.ar] "viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz cerra tus ojos que sobra lugar en idilia para los dos"
participants (3)
-
Carlos Villavicencio -
josx -
Ovnicraft