Conversión de bases v7 a v8

Los administradores que ya hayan trabajado con Ingrid v7 encontrarán aquí información para entender el cambio de plataforma, el cambio de modelo de datos, y las herramientas para portar toda la información compatible de bases de la versión 7 a la 8 (no el proceso inverso).

 

En la BD comun de Ingrid 7 existe un procedimiento Javascript para exportar a formato JSON toda la información de una BD: Utilidades> Traslado de BD y MongoDB> mongoExporta · Exporta base actual a MongoDB.

Este archivo, se importa con un procedimiento de MongoDB y en un solo paso, se tiene la BD accesible en Ingrid 8 en todo los qeu la diferencia de ambos modelos de datos permite, principalmente, los objetos y espacios con sus campos de datos.

A partir de ese momento, se gestionar toda la información desde el interface web de Ingrid 8: gestión de usuarios, estructura de carpetas en la jerarquía de la base, definición de clases y campos, gestionar los datos de cabecera que permiten la representación geográfica sobre fondos estándar de Google maps, Bing, OpenStreetView...

En el lado cliente, los administradores pueden programar algunos scripts con el API que el servidor permite al cliente: buscar en  BD, volcar información a archivos, y principalmente, mostrar informes html para explotar la información de la base.

Requerimientos especiales al convertir

Los archivos (gráficos, documentos, directorios, etc.) externos a la BD versión 7 hay que reestructurarlos con las condiciones que requiere el motor de Ingrid 8. Además se tiene que cumplir que los gráficos estén vinculados (no incrustados, ni referenciados) y en modo web, con las versiones media y baja generadas.

No existen códigos de bloque en geomapa, los bloques son los de la representación de la familia o clase.

Los nombres de BD no pueden tener espacios en blanco, caracteres acentuados, ni fuera del ASCII estándar.

Los códigos de tipos, clases o familias no pueden ser numéricos, si hay alguno se avisa en la exportación

 

Sólo se admiten familias con elementos de una única clase. El flag de aplicación Proyecto> Parámetros generales> otros> Comportamiento de familias: Se admiten múltiples clases, no puede estar activado al exportar. Por ejemplo la base demoAreasInfantiles. Hay que reorganizar las familias en v7 duplicando las familias que sean necesarias, para que sea un árbol único tipo -> clase -> familia -> concepto.

Se exportan todos los rótulos aunque no estén utilizados en referencias. Mapear siempre bien las familias y ascendientes de clases, sino el campo padi o fami no saben a qué clase hacer referencia

IMPORTANTE:

1. atención con referencias como la de las OTs, que en ordcon tendrán referencia al inventario, y al exportar serán referencias que pueden definir dónde colgar las familias (clases en v8) de inventario. Esa información obsoleta puede perjudicar.

2. Prestar mucha atención a que las clases se correspondan geográficamente con UNA capa (no importa el código). Al tomar colores de las capas v7 para las clases v8, se cogerá para cada clase la primera capa (si tiene varias georreferencias en varias capas distintas) asociada al primer concepto (ordenados por ide), de la clase.

3. Siempre chequear el geomapa para asegurarse de que todas las coordenadas están correctas. Se debería chequear la base también para evitar referencias incorrectas, tablas vacías...

Limitaciones de la conversión

A fecha marzo-2017. No se exportan DE FORMA AUTOMÄTICA:

- tablas perano, perdiatip de disponibilidades de personas
- variables gra_director, ref_director, en MongoDB la estructura es forzada y viene en el servidor como directorio de bases MongoDB. No se consideran tabperano_modos, tabtraano_modos
- propiedades de objetos RFID: tablas rfe, rfl, tel ni tablas de relaciones telent, telsal
- tablas web, fieado
- histórico de campos concam
- textos múltiples de tabla tex, ni contenido RTF
- relación de precios de compra por entidad o por tipo/hora
- de información del geomapa: ni análisis ni términos
- equ: tabla consumos equcon
- campos que apuntan a múltiples rótulos (como acc._tip o acc._rie)
- Las familias se convierten en clases por ello no puede haber conceptos de distintas clases pertenecientes a la misma familia.
- En web: eventos programados en iwebdoc con funciones iwebdoc_graba(), iwebdoc_grabado()... ahora hay que programarlas en los eventos de cada clase

Esta información se puede modelizar en la versión 8 y pasar los datos de las bases v7 mediante un script que vuelque los datos en el formato JSON deseado, pero ya sería una exportación particular.

Cambios en el modelo, respecto a Ingrid 7

No existen tablas, todos los documentos (equivalentes a registros) pertenecen a una clase y se encuentran todos en la misma tabla o colección del motor mongoDB.

- El campo cod es ahora _id y tiene la clase y código separados por punto, como: jararb.0001
- Desaparece el ide interno no visible, ahora todas las referencias son por el campo  _id: clase.codigo
- La definición de clases se hace en registros documento con _id= .<codigoDeClase>
- Las variables de cabecera están en el documento _id= .  , junto a la definición de los campos base comunes a todos los conceptos: fec, pre, can...
- Las unidades de medida (rótulo tipo 1) pasan a un texto simple que ni siquiera es fijo de la aplicación
- Los rótulos se definen en cada clase (en campos tipo #) y quedan encapsulados ahí. Esa "subtabla" de datos admite ampliarse con cualquier definición de campos.
- BAN y sus líneas de movimientos BANLIN se importan, aunque la filosofía de relacionar movimientos con documentos (conciliar) ha cambiado un poco y está más relacionada con la contabilidad.
- GRA se incorporan con todos los datos en una lista gral en cada documento
- RCC.des de carpetas o de cualquier otro tipo o clase, se pone en una lista desl de cada documento (rcc.com)
- MAPGEO pasa a la lista geol de cada concepto (documento mongoDB)
- Las tablas auxiliares de DOC: doclin, docpag, docseg, así como las de tareas TAR, tarper, tarequ, tarrec... pasan a listas de documentos definidas en clases DOC y TAR: desl, pagl, segl
- Las medidas dejan de ser conceptos y se convierten en listas medl en la clase .ope (operaciones).
- SEGUSU, SEGGRU pasan juntos a ser usuarios, clase .usu, pero los usuarios se pueden agrupar en otros (que serán los grupos)
- Los ámbitos de permisos (con.amb) se mantienen en el mismo campo, pero ya no se gestionan con una jerarquía de un código de ámbito en el grupo de usuarios, que puede contener (acceder) a otros, sino que cada usuario tiene un rango de ámbitos que puede ver.
- En definición de campos, los que tienen un icono de chincheta son re-definibles en posición, pero no se puede cambiar el código, ni el tipo, ni eliminarlos. Son fijos para uso de Ingrid.
- Las clases de tareas preventivas y correctivas derivan de una clase TAR organizativa, pero no tienen campos en común: todas las fechas de cierre, programación, textos, medidas... son campos de cada tabla por separado.
- Ya no hay operaciones ligadas que no coincidan exactamente en el tiempo (por ejemplo, anuales ligadas a semestrales de un mismo bin), sí se pueden ligar las que tengan sobre los mismos bin EL MISMO patrón temporal.
- No hay concepto orden de trabajo diaria (o varias) sólo una lista de tareas por fecha y por grupo de trabajo, con todas las pendientes. El parte de trabajo diario son todas las cerradas en una fecha para un grupo.

Cambios respecto al Geomapa de Ingrid Windows

La representación geográfica es sólo la asociada a conceptos (es decir en la tabla de mapcon de v7). Los conceptos sin georreferencia no salen en la lista de conceptos, y tampoco se muestra ninguna representación geográfica "vacía", sólo el grafismo que no tenga asociado un concepto.

La correspondencia de información es la siguiente:

Windows v7 Web v8
Geomapa  No hay página o ventana de representación global de toda la info geográfica, sino que cada elemento muestra la suya (opcionalmente la de sus hijos, padres...)
Mapa  No existen conceptos de BD con la información geográfica, sino que está en cada concepto (documento de BD mongoDB).
Capas  Clases. Llamamos clase ahora a las Familias, los Tipos y Clases de v7
Espacios  Igual: concepto de clase Espacio (esp)
Entidades Línea, Punto, Círculo, Texto, Bloque... Parecidos: listas de puntos con distintas tipologías de entidad (Líneas y curvas abiertas y cerradas: (L,P,C,O y Rectángulos, Elipses, Bloques y Textos)

 

Al exportar, se convierte los textos en bloques de 1 punto sin representación de bloque y con el texto centrado. Ahora hay entidades:
B - bloque de 1 ó 2 puntos. el segundo punto es el extremo central derecho de la envolvente y permite definir a la vez el tamaño y rotación del bloque: se convierten los 3 puntos anteriores en estos dos.
L - Línea abierta de 2 ó más puntos
P - Polígono cerrado de 3 ó más puntos, con relleno el de v7 con transparencia 50’%
C - Curva cerrada (o elipse), se define con 2 puntos (vértices extremos que dan también al dirección de giro) y un factor de proporción partiendo del círculo como proporción 1:1
R - Recuadro como la envolvente de la curva, con 2 puntos y un factor de proporción.
 

Cambios en la filosofía de acceso a BD

Con la filosofía de mongoDB, el caso habitual es procesar en el cliente los datos a grabar y enviar una sola (o pocas) funciones de grabación con todos los datos a crear o modificar: hay que olvidarse completamente, por ejemplo, de bucles iterativos con las funciones de grabación por campos y registros unitarios. Para ello tenemos:
bas.creaConceptos() - sólo graba si no existe, con parámetro ordered:false, no se para si existe y da error, pero no permite regrabaciones de datos, claro
bas.recreaConceptos() - graba siempre el documento completo, machaca todo la información que no se grabe, no sirve para modificaciones parciales
bas.grabaConceptos() - actualiza docs, actualiza campos de cada documento

Cambios en el sistema de archivos

Ahora que los archivos están en el formato del motor de BD mongo, la copia completa de una BD puede ser legible (en formato JSON) o binario, mucho más rápido de exportar e importar (en formato BSON). Para consultar una BD de una versión anterior, hay que crear una nueva base en el motor de mongoDB e importar el BSON o JSON deseado.

La descripción de cómo y dónde están las copias de seguridad, esta en: Base (admin)