Blog

Campos objeto en V7

Campos Objeto

En este momento nos encontramos trabajando y ultimando el núcleo de Velneo en el ámbito de los datos que se guardan en la base de datos. Una vez que ya están trabajando los campos alfabéticos, numéricos, fórmula, etc., les tocaba el turno a los campos objeto. También éstos van a sufrir algo más que un re-styling en V7.

Formatos

En primer lugar, de partida vamos a tener campos objeto de tipo texto, texto enriquecido (ya visteis anteriormente el nuevo editor que tiene), binario y dibujo. Luego veremos qué hacemos con los de tipo E-mail y los de tipo OLE (estos últimos, como no son multiplataforma, no podemos usarlos).

Los campos de tipo objeto tendrán una mejor accesibilidad, por ejemplo: podremos importar y exportar los campos texto enriquecido, cosa que en V6 no era posible.

Además, teniendo en cuenta que serán multiplataforma, los campos tipo dibujo admitirán JPG, PNG y otros formatos que se guardarán como JPG o PNG según sea el origen, permitiendo a su vez exportarlos de nuevo a esos formatos (BMP, etc.).

A la hora de guardar los dibujos en formato JPG tendremos dos opciones: si lo pegamos como bitmap (ya renderizado) será V7 la que se encargue de comprimirlo bien en JPG, bien en PNG, según sea el formato elegido, pero en cualquier caso la imagen no sufrirá pérdida alguna de calidad. El formato JPG lo usaremos para imágenes grandes, con millones de colores y el formato PNG además admite transparencias y paletas de colores.

Por otro lado, también admitirá guardar imágenes JPG en formato comprimido, respetando la imagen tal cual está en disco. Este es el caso, por ejemplo, de las fotos que hacemos con una cámara de fotos. Al tenerlas en disco e importarlas, las guardará tal cual, sin procesarlas. Esto evitará pérdidas de calidad que puedan venir causadas por tener que renderizar previamente la imagen y luego volver a comprimirla dentro de la base de datos.

Indexación en objetos texto

Otra novedad en la que nos encontramos trabajando, y que podremos probar próximamente, es la indexación de los campos objeto texto. Las limitaciones que en V6 existían para ese proceso han sido tenidas en cuenta en el diseño de V7, y la indexación de los campos objeto texto ya se podrá realizar a nivel de ficha, como si fuera un campo más.

De esta manera dispondremos de indexación por palabras y de trozos, lo que hará aún más potente si cabe Velneo. Además, la indexación por palabras admitirá la configuración de listas negras (es decir, palabras que no se incluirán en la indexación).

Campos objeto en V7 1

Optimización

En primer lugar, los objetos no viajarán si no hay modificaciones, y si lo hacen, viajarán comprimidos. Así, cuando guardemos una ficha o leamos una ficha en vClient, si el campo objeto no ha sido modificado, ni en la lectura ni en la escritura se enviará el campo objeto del cliente al servidor o viceversa. De esta manera evitamos un tráfico innecesario y que ralentizaría a la hora de realizar estas operaciones. Únicamente en el caso de que accedamos a la lectura o modifiquemos un campo objeto, este será enviado del servidor al cliente y del cliente al servidor respectivamente.

Si a esto añadimos que vamos a disponer de una caché en memoria, trabajar con campos objeto va a ser una delicia. Unido con lo anterior quiere decir lo siguiente:

Cuando cargamos una lista en una rejilla o un registro en un formulario, el campo objeto de la ficha correspondiente no se carga si no se muestra. En el momento de mostrarlo se realiza la carga, pero si ya está en la caché, no se va a buscar al servidor, si no que se carga directamente de la caché. Si en el formulario realizamos cambios, pero no tocamos el campo objeto, al aceptar la ficha sólo viajarán el resto de datos y no el objeto. Únicamente, si tocamos el campo objeto, este viajará de vuelta al servidor. Desde luego, el refresco terciario se encargará de refrescar los objetos que hayan cambiado otros usuarios en el servidor.

En el ámbito de la indexación, la indexación de textos va a ser muy eficaz. Aún así, se han preparado optimizaciones importantes: por ejemplo: sólo se reindexarán las diferencias con el texto anterior, con lo que la indexación en modificación se va a ver optimizada.

Y la última novedad que traerá el tipo de campo objeto, y no por ello menos importante, es la compresión de objetos en el fichero contenedor (CND): los campos objeto van a estar comprimidos dentro del CND. Para las imágenes y los objetos binarios que ya se encuentren comprimidos no será importante, pero para textos y otros objetos que no lo estén, esta optimización resultará muy efectiva. Además, los procesos de compresión y descompresión los realizará el cliente (excepto en trabajos en tercer plano, claro está), por lo que libraremos de esa carga de trabajo al servidor, no representando ninguna carga para el cliente, con los beneficios que reporta para el trafico en Internet de los objetos comprimidos.

18 thoughts on “Campos objeto en V7

  1. Buenas tardes:

    Entendido. El artículo no menciona nada acerca del archi-famoso problema de impresión de los objetos texto en V6.

    Supongo que esto también se resolverá, para no tener que hacer la ñapa de trocear el objeto texto para imprimirlo. Simplificaría mucho el uso de estos objetos en informes.

    Un saludo,

    Fran.

  2. Ampliando sobre lo que dice Fran, se hace indispensable poder incluir el objeto rtf en un infome para su impresión. Hasta ahora hay que complicarse mucho la vida para realizar un informe un poco complejo, ya sea como dice Fran troceando el texto, pasando a word o realizando informes HTML, se debería poder realizar informes incluyendo este tipo de objeto asi como optimizar el objeto informe, paginaciones, etc.

    Un saludo

  3. En cuanto a lo de los objetos OLE me preocuparía que el «ya veremos que hacemos» se traduzca en que no teneis previsto incorporarlo. Actualmente el poder incorporar objetos OLE dentro de la propia base de datos es uno de nuestros mejores argumentos de venta.

    ¿Sería posible que en función de la plataforma utilizada (Windows y en Mac creo que había algo similar) se puedan guardar o no estos objetos en la base de datos? Claro que os complicará la portabilidad entre plataformas, pero pienso que el esfuerzo merece la pena.

  4. Muchas gracias por vuestros comentarios, paso a comentaros algunos puntos de vuestros comentarios.

    -Visores editores de Campo Objeto Texto Enriquecido

    El campo objeto texto enriquecido esta basado en HTML / XML y no son formato nativo RTF.

    Existe un editor de objetos texto y objetos texto enriquecido en formularios y un visor de dicho campo en los informes.

    Al desligarnos del formato nativo RTF que daba incompatibilidades y problemas en su gestión nos permitirá dar más posibilidades tanto al editor en el formulario como al visor que renderizará el texto para impresión.

    -Campo Objeto

    En este artículo intentamos comentar el funcionamiento de los campos objeto referidos a la base de datos, almacenamiento y gestión, los controles que lo gestionan lo atacarán de formas muy distintas, ya que este campo será accesible desde un formulario, rejilla, informe, etc

    -Objetos OLE

    Los objetos OLE, desaparecerán no solo por no ser multiplataforma sino porque no están soportados por su propio creador ( Microsoft ).

    Para el almacenamiento de los archivos no existe ningún problema, ya en las versiones 6.x se contaba con almacenamiento en la base de datos de cualquier binario. Lo que realmente lo complica es la gestión de ese binario con el usuario y el sistema operativo.

    Lo que si tenemos claro que tenemos que abrir la plataforma y base de datos al almacenamiento y gestión de elementos «desconocidos», estos elementos pueden variar desde PDFs, DWGs, Swf, etc.

    Para ello con apoyo del antiguo campo binario y unos elementos extensivos de V7, podemos permitir gestionar cualquier elemento «desconocido» desde el interfaz de V7. Aquí no puedo adelantaros mucho ya que no tenemos nada en funcionamiento y este tema lo tenemos en fase de diseño.

  5. Gracias a todos por vuestros comentarios.

    Estimado amigo de CEESA:

    El dato al que te refieres como límite es debido al tiempo que se encuentra un proceso que transacciona sin realizar operaciones. Normalmente te pasará en el cliente, porque si el proceso está en el servidor, en tercer plano, importará directamente de disco y el fichero podrá tener el tamaño que desees y no saltará el timeout.

    En concreto, el objeto binario, que es el que sustituye al objeto OLE, tiene un límite teórico de 4 GB, mientras que el objeto texto admite 4.000 millones de caracteres. En cualquier caso, en V7 estos límites se ampliarán en función de las necesidades.

    Estimado César Moreno:

    Indexar únicamente las diferencias en el objeto texto implica que, como parte de vacío, es decir, el contenido es nulo, cuando introduzcamos el primer valor al campo texto, indexará este por completo, ya que será completamente distinto al contenido anterior, la diferencia seá el total del contenido.

    Y en la modificación, volverá a indexar de nuevo únicamente las diferencias con el contenido anterior, optimizando de esta manera la funcionalidad de la indexación de los campos objeto texto. Es decir, no borrará la indexación generada con el anterior contenido, para volverla a generar de nuevo, si no que comprobará qué ha cambiado y reindexará esa parte.

    Gracias a todos por vuestros comentarios.

    Un saludo

  6. Lo de forzar a indexar todo el objeto texto, lo digo por si fuera necesario, en un caso extremo, donde pudieramos sospechar que estubiese dañado el indice. Una opción sería borrar el fichero indice, pero la veo demasiado brusca.

    Un saludo: César.

  7. Con la opción regenerar indices se realiza una regeneración total de todos los indices incluidos los que contengan una parte con un Objeto texto, con lo que no es necesario borrar el fichero de indice, que como bien comentas es un poco «brusco»

    Saludos

  8. Hola,
    He hecho una apliciacion con vdevelop de control de fichas.
    Tengo entradas 30 fichas con cada un con una imagen.jpg cada imagen ocupa 200 Kb.
    Para entrat una ficha tarda mucho tiempo no se podria hacer que fuera mas radipa a cargarse?
    Adeu

Dejar un comentario