Estándar para Serializar datos
 

Hola a todos

Antes que nada, gracias desde ya por leer mi consulta.

Utilizo Delphi 6 y Firebird.
Hasta el momento utilizaba clientdataset para manipular datos y guardarlos en un archivo propio de los clientdatasets (.cds) para transportar esta información hacia otras aplicaciones Delphi.

Ahora, los entornos cambiaron y necesito compartir esta informacion pero también desde sistemas linux.
Desarrollé unas pruebas en python en Linux que toma datos de la base, los serializa (cPickle), los comprime y los guarda en un archivo binario. También hice su contrapartida, abre, descomprime, deserializa. La información es texto e imágenes.

El problema es que necesito que ese archivo pueda ser procesado también por una aplicación en Delphi para lo cual necestaría que el método, sobre todo el de serializar/desarializar, sea standard y pueda ser reconocido por otros lenguajes. En este sentido estoy algo perdido y hasta el momento no he encontrado nada.

Podría ejecutar el python desde Delphi, pero digamos que esto es casi inviable ya que las máquinas donde va a correr la aplicación delphi son de clientes y sería complicado instalar python en cada una de ellas.

Mi mayor problema es la serialización/desarialización, necesitaría un método standard, rápido y que maneje los datos en forma binaria para ocupar menos espacio.

Muchas gracias nuevamente

Un abrazo

Walter

No tengo claro de a qué te refieres exactamente con serialización/desarialización.

Casimiro

Tengo entendido que para persistir o transmitir datos y asegurarnos de que la estructura y el contenido de los mismos se mantengan durante el proceso, lo mejor es serializar la información. Por ejemplo, para manejar datos a través de internet se puede utilizar JSON, XML, etc

Gracias por tu atención y cualquier sugerencia es bienvenida.

Bien, puedes usar lo que comentas o cualquier otro que te venga bien. En mi caso los envios/recepciones de datos entre sucursales/representantes/etc. las hacemos en formato texto normal, comprimido con clave, obviamente.
Realmente se envian a un servidor ftp y los demás se encargan de comprobar si hay algo para ellos en el ftp y descargarlo, descomprimirlo, instalarlo, etc. todo automáticamente, sin necesidad de que el usuario intervenga.

El tema es que no trabajo solo texto, si no que también deben viajar imágenes tomadas de un campo BLOB de la base.
Lo que quiero hacer es "imitar" el comportamiento de los archivos que generan los clientdatasets ya que hasta hoy era lo que manejabamos y funcionaba de 10.
La traba es que ahora estos archivos deben ser generados desde una plataforma Linux y leídos por aplicaciones en Delphi en Windows.

Entonces creo que no he entendido el problema, todos los servidores de mis clientes tienen instalados linux+firebird.
Puedes guardar las imágenes con un nombre que sea la referencia/código y empaquetarlas juntas para enviarlas, luego en su destino se desempaquetan y se importan a la base de datos destino.

¿Y cómo empaquetas o qué significa empaquetar la imagen?

// Saludos

Con empaquetar me refiero simplemente a almacenar en un .zip

¡Ah! O sea que tu método consiste en mandar el archivo de texto junto con uno o más zip que contienen los datos binarios. ¿Es así?

Pienso que también podría usar un XML como mencionaba. En el caso de las imágenes, podría codificarlas con base64 o similar para convertirlas en texto y poderlas poner en el xml.

// Saludos

Sí, depende de lo que se haya actualizado en la base de datos, pueden ir sólo textos, imágenes o ambos ficheros juntos en un archivo zip.
Cuando se hizo esa opción no estaba muy difundido xml, o mejor dicho, yo no lo conocía :D, de eso hace unos 14 años y es el mismo sistema que he ido implementando en cada nuevo proyecto. Es sencillo, rápìdo, eficaz, seguro... así que para qué cambiarlo :)

Una conocida máxima en programación dice: "Si funciona no lo arregles."


Un Saludo.

El problema que tengo es que las imágenes no las quieren en archivos, por eso se extraen de una base de datos y al transmitirlas se vuelven a guardar en otra base.

El problema con xml y json es que agregan notaciones y eso hace crecer considerablemente el tamaño del archivo, a pesar de comprimir antes guardar.

El método que creé en python para probar, comprime y serializa los datos en forma binaria y es muy fácil deserializarlos, desde python obviamente.

De todos modos, probé utilizar xml y efectivamente el tamaño del archivo crece demasiado.

La variante que encontré (y tal vez sea no intentar reinventar la rueda) es utilizar una base de datos intermedia, sqlite. Que soporta campos blobs, es cross-plataform, existen drivers para muchos lenguajes, el archivo de la base es transportable y además no necesita ninguna instalación en el cliente. Por supuesto me cambia bastante el manejo de la aplicación teniendo que agregar componentes y demás, pero bueno, por el momento me parece que voy a demorar menos que seguir intentando reproducir el cds de los clientdatasets.

Si a alguien se le ocurre alguna otra sugerencia, bienvenido sea.

Un abrazo y mil gracias por las sugerencias y comentarios.

No había pensado en sqlite. Creo que es una excelente opción.

// Saludos

Gracias Roman, espero que si, aún no lo he probado

Un abrazo