Hola a todos, tenemos una duda sobre la migración y los pasos correctos.
Actualmente tenemos KOLLA 4.8.0 en producción en un servidor Debian 11 y en paralelo armamos un servidor Debian 12 con Kolla 4.9.3 ya que utilizan versiones diferentes de PHP.
La duda es si primero se debe correr la actualización en 4.8.0 y después restaurar el backup de la bd en 4.9.3 o hay alguna forma alternativa de hacerlo?
Desde ya muchas gracias, saludos cordiales.
Pablo.-
Con relación al Debian 11 no van a poder correr la actualización porque la versión de php no va a cumplir los requisitos y no los va a dejar avanzar.
Van a tener que copiar la estructura de directorios de la instalación actual y replicarla en el Debian 12. La actualización se realiza siempre apuntando a la base actual, asi que también pueden hacer el dump y restaurarla en el Debian 12 para directamente correr todo el proceso de actualización allí.
La ventaja de hacerlo de esa manera es que la instalación actual no se toca, por lo que si algo no funciona bien, no se daña el Kolla que tienen en uso. Deben recordar pasar a modo mantenimiento manualmente la instalación actual desde el momento en el que comienzan con el proceso y hacen el dump de la base de datos, para que nadie ingrese en esa ventana de tiempo, ya que perderían esa información.
Reapaso entonces lo que me comentás:
1-Copio la estructura de archivos del directorio Kolla 4.8 en Debian 12 , no molesta que requiera 7.4…?
2-Restauro el backup de la BD de producción en el Servidor Debian 12
3-Corro los script de migración
4-Finalmente la instalacion de 4.9.3 de cero que hicimos la descarto y dejo corriendo la 4.8 en Debian 12 o reemplazo el directorio…?
Hola Pablo buenas tardes, te dejo aclaraciones según los puntos indicados:
Punto 1: Es solo copiar la estructura de archivos completa. Respetando paths. No tiene que correr ningún comando, por lo tanto no le va a afectar que sea otra versión de php
Hola Yudith buenas tardes, te consulto porque nos encontramos con un problema realizando la actualizacion de version de 4.8.0. a 4.9.3
Te detallo todos los pasos realizados en el servidor nuevo 4.9.3:
1-Instalacion de version 4.9.3 de cero y base de datos en blanco y quedo funcionando!
2-Copiamos carpteta Kolla 4.8.0 a servidor nuevo
3-Restauramos BD Kolla 4.8.0 reemplazando la BD 4.9.3 nueva
4-Ralizamos los pasos de actualizacion de 2 formas: ./bin/instalador proyecto:actualizar
-La primera detecta que la carpeta /instalacion existe y aborta el proceso.
-La segunda es borrando dicha carpeta , que deja terminar el proceso pero tira el siguiente error:
2026-05-20T17:19:25.602122+00:00] MAIN.INFO: [ TOBA ] La opcion ‘migrar’ no existe Administracion de PROYECTOS
Alguna sugerencia de que puede ocurrir? Lo extraño que realizamos los mismos pasos hace 2 meses y andaba perfecto. Pudo haber cambiado el Framewor en estos meses y al realizar nuevamente el Composer Install se rompio algo?
Buenos días, añadiendo a lo que posteo Pablo, recién intentamos hacer una actualización limpia desde 4.8.0 a 4.9.3 y nos encontramos con un problema en un campo de la tabla sge_habilitacion.
Adjunto el log del error.
[2026-05-21T12:51:08.127889+00:00] MAIN.INFO: [ COMANDO EJECUTADO ] php /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/toba
[2026-05-21T12:51:08.257341+00:00] MAIN.INFO: [ TOBA ]
[2026-05-21T12:51:08.258195+00:00] MAIN.INFO: [ TOBA ] Comienza el proceso de migracion de version 4.8.0 a 4.9.3
[2026-05-21T12:51:08.280361+00:00] MAIN.INFO: [ TOBA ] Migrando a version 4.8.2 negocio__45753
[2026-05-21T12:51:08.348533+00:00] MAIN.INFO: [ TOBA ] OK
[2026-05-21T12:51:08.348770+00:00] MAIN.INFO: [ TOBA ] Migrando a version 4.9.0 negocio__45644
[2026-05-21T12:51:08.364593+00:00] MAIN.INFO: [ TOBA ] ERROR ejecutando SQL: [CODIGO]: 7 [SQLSTATE]: db_42701 [MENSAJE]: ERROR: ya existe la columna �limite_global� en la relaci�n �sge_habilitacion� [SQL EJECUTADA]: ALTER TABLE IF EXISTS sge_habilitacion ADD COLUMN limite_global integer DEFAULT NULL, ADD COLUMN limite_individual char(1) DEFAULT ‘N’; ALTER TABLE sge_habilitacion ADD CONSTRAINT ck_sge_habilitacion_limite_individual CHECK (limite_individual IN (‘S’, ‘N’));
[2026-05-21T12:51:08.365297+00:00] MAIN.INFO: [ TOBA ] PHP Fatal error: Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php:18 Stack trace: #0 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php(18): explode() #1 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(163): toba_texto::separar_texto_lineas() #2 /usr/local/proyectos/kolla-4.9.3/php/modelo/migraciones/kolla_migrador.php(90): consola->error() #3 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_modelo.php(91): kolla_migrador->migrar() #4 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_comando.php(28): kolla_modelo->migrar() #5 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comandos/comando_proyecto.php(87): kolla_comando->opcion__migrar() #6 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comando.php(90): comando_proyecto->ejecutar_opcion() #7 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(78): comando->procesar() #8 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(55): consola->invocar_comando() #9 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/run.php(32): consola->run() #10 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/launcher.php(31): require_once(‘…’) #11 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/toba(2): require_once(‘…’) #12 {main} thrown in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php on line 18
[2026-05-21T12:51:08.376352+00:00] MAIN.ERROR: El proceso no pudo finalizar correctamente. ERROR ejecutando SQL: [CODIGO]: 7 [SQLSTATE]: db_42701 [MENSAJE]: ERROR: ya existe la columna �limite_global� en la relaci�n �sge_habilitacion� [SQL EJECUTADA]: ALTER TABLE IF EXISTS sge_habilitacion ADD COLUMN limite_global integer DEFAULT NULL, ADD COLUMN limite_individual char(1) DEFAULT ‘N’; ALTER TABLE sge_habilitacion ADD CONSTRAINT ck_sge_habilitacion_limite_individual CHECK (limite_individual IN (‘S’, ‘N’)); PHP Fatal error: Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php:18 Stack trace: #0 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php(18): explode() #1 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(163): toba_texto::separar_texto_lineas() #2 /usr/local/proyectos/kolla-4.9.3/php/modelo/migraciones/kolla_migrador.php(90): consola->error() #3 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_modelo.php(91): kolla_migrador->migrar() #4 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_comando.php(28): kolla_modelo->migrar() #5 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comandos/comando_proyecto.php(87): kolla_comando->opcion__migrar() #6 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comando.php(90): comando_proyecto->ejecutar_opcion() #7 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(78): comando->procesar() #8 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(55): consola->invocar_comando() #9 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/run.php(32): consola->run() #10 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/launcher.php(31): require_once(‘…’) #11 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/toba(2): require_once(‘…’) #12 {main} thrown in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php on line 18
[2026-05-21T12:51:08.376592+00:00] MAIN.ERROR: ERROR ejecutando SQL: [CODIGO]: 7 [SQLSTATE]: db_42701 [MENSAJE]: ERROR: ya existe la columna �limite_global� en la relaci�n �sge_habilitacion� [SQL EJECUTADA]: ALTER TABLE IF EXISTS sge_habilitacion ADD COLUMN limite_global integer DEFAULT NULL, ADD COLUMN limite_individual char(1) DEFAULT ‘N’; ALTER TABLE sge_habilitacion ADD CONSTRAINT ck_sge_habilitacion_limite_individual CHECK (limite_individual IN (‘S’, ‘N’)); PHP Fatal error: Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php:18 Stack trace: #0 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php(18): explode() #1 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(163): toba_texto::separar_texto_lineas() #2 /usr/local/proyectos/kolla-4.9.3/php/modelo/migraciones/kolla_migrador.php(90): consola->error() #3 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_modelo.php(91): kolla_migrador->migrar() #4 /usr/local/proyectos/kolla-4.9.3/php/extension_toba/kolla_comando.php(28): kolla_modelo->migrar() #5 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comandos/comando_proyecto.php(87): kolla_comando->opcion__migrar() #6 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/comando.php(90): comando_proyecto->ejecutar_opcion() #7 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(78): comando->procesar() #8 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/consola.php(55): consola->invocar_comando() #9 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/consola/run.php(32): consola->run() #10 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/launcher.php(31): require_once(‘…’) #11 /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/bin/toba(2): require_once(‘…’) #12 {main} thrown in /usr/local/proyectos/kolla-4.9.3/vendor/siu-toba/framework/php/lib/toba_texto.php on line 18
estos pasos que detallas acá no son correctos para actualizar.
El paso 1 les sirve para tener una instalación del módulo en versión 4.9.3 funcional y lista para trabajar pero sin los datos previos que puedan tener de usos anteriores.
Para actualizar la instalación 4.8.0 que tienen a una versión posterior (4.9.3 o 4.10) deben copiar la carpeta al nuevo servidor como dice tu paso 2, luego descomprimir en otra carpeta (la definitiva) el instalador de la nueva versión, y a partir de ahí correr los comandos de cada paso de la actualización. En este enlace pueden revisar en detalle paso a paso cómo hacer la actualización.
No se bien a qué te referís con “actualización limpia” pero si hicieron los pasos que mencionó Pablo más arriba es por eso que les falla, no tienen que crear una base nueva antes de actualizar. Para actualizar cambiando de servidor necesitan:
copiar la carpeta de instalacion en el nuevo servidor
si también cambia el servidor de base de datos, deben obtener un dump de la base y restaurarlo en el nuevo postgres tal como está
descomprimir el archivo del instalador
correr los procesos de actualización: eso va a “leer” la instalación anterior y realizar los cambios necesarios en la base para dejarla en la nueva versión.
Una vez terminado el proceso la carpeta con los archivos fuente será la nueva, y la anterior ya no se utilizará; la base de datos será la misma, actualizada.
Hola Clara, hice los pasos exactamente como indicas y el error que da es el que puse arriba, sera que tenemos que irnos a la 4.10 para evitar estos problemas?
Previamente a que salga la version 4.10 habiamos podido actualizar sin problemas a 4.9.3 con esos pasos, pero ahora necesitamos actualizar la base porque siguieron trabajando en la 4.8.0 y nos encontramos con este error.
Vamos a intentar una prueba con la version 4.10 y necesito los permisos para descargarla del repositorio porque no la veo disponible, la carpeta esta vacia.
El error que se ve en el log que copiaste es que se está intentando sumar un campo en una tabla de la base y se encuentra que el campo ya existe. Eso indica que la base sobre la que se quiere correr el cambio ya fué actualizada porque el campo se agregó en versión 4.9.0
Revisá el archivo instalador.env que estás usando para la actualización, seguramente quedó apuntando a una base de datos que ya está en versión 4.9.0
Pablo, chequeá por favor con qué usuario están ingresando al portal Comunidad, porque revisamos el contenido y los permisos del repositorio y deberías estar viendo el instalador de 4.10, te comparto una captura de lo que hay.
Recuerden por favor iniciar el proceso de actualización desde un backup de la carpeta y de la base de datos que esté en la versión de origen, sin cambios ni actualizaciones.