Lazarus, Linux, ZeosLib, Firebird. ¿Qué combinación funciona?

[rolandoj]

Empezado por Casimiro Notevi

Supongo que ese TZReadOnlyQuery no permite volver hacia atrás en los registros. Normalmente los TDataSet tienen la propiedad "UniDirectional", para indicar si sólo avanza hacia adelante o si guarda información para poder volver hacia atras.
Por lo visto ese tzreadonlyquery es como un TIBQuery o un TFIBquery, que tienen siempre el UniDirectional a False, para ocupar menos memoria y ser más rápido, es perfecto para consultas, informes, etc. Pero si si quiere hacer un mantenimiento presentando datos y que el usuario los recorra a su gusto... entonces no valen, hay que usar el TIBdataset o el TFIBdataset, estos son de IBX y FIbplus, respectivamente.
O sea, el "fallo" que te aparece no es un fallo, es una característica de ese componente que lo estábais usando indebidamente.

Hola,

Nosotros estamos trabajando es en un servidor. El componente no existe en el lado cliente; nuestro esquema correcto es avanzar solo hacia adelante (FORWARD ONLY) y el mensaje de error confirma que efectivamente el componente se está comportando bien.

En ese sentido, tal componente no debería ni siquiera tener esa propiedad, ya que se supone que es su comportamiento natural. De todas formas, tú idea puede estar en la dirección correcta, al suponer un mal uso de una propiedad, por lo siguiente:

Nosotros solo cambiamos, Name, Database y SQL; pero, nuestro sistema de prueba está lento porque usamos es máquina virtual en un equipo con poca memoria; así que yo ayer estaba pensando que quizás al ajustar las propiedades del componente accidentalmente modificamos alguna. No hay que descartarlo. Hoy revisaremos.

[Casimiro Notevi]

Empezado por rolandoj

De todas formas, tu idea puede estar en la dirección correcta, al suponer un mal uso de una propiedad, por lo siguiente:[..]

Bueno, no sé si será eso o no, era sólo una idea para que puedieras verificarlo.

Si usas una máquina virtual entonces asegúrate de tener suficiente memoria RAM para el servidor y para el "servido"
Si tienes más de una cpu (física o virtual) también ponlo en la configuración, notarás la diferencia de la MV.

[rolandoj]

Hola,

Ya verificamos y efectivamente se trata de un problema de Zeos. Nosotros hicimos una corrección al código fuente de Zeos, lo reconstruímos y ya trabajó bien.

Más tarde les daré una explicación detallada porque el arreglo fué de emergencia; quiero estudiar más a fondo el código Zeos para determinar con mayor exactitud la causa e implicaciones tanto del problema como de la solución que aplicamos.

Les adelanto que al avanzar en las pruebas encontramos otros dos problemas que potencialmente son de mucha importancia. Uno es quizás una limitante de Zeos y el otro un problema de diseño del Web Module. Vamos también a analizarlos en detalle antes de reportarlos aquí

Saludos

[roman]

Aunque ZEOS ha sido un buen proyecto, pienso que no sería recomendable usarlo en futuros desarrollos. Basta fijarse en su portal para darse cuenta de que no ha habido cambios ¡en casi dos años!

Además, la versión 7 se quedó en alpha, o sea, nada recomendable para producción

// Saludos

[rolandoj]

Hola Roman,

Gracias por aportar.

En principio, el argumento es válido; pero, consideremos lo siguiente:

1. Si no es Zeos, quién ?. Nadie nos ha sugerido ninguna otra opción que satisfaga nuestras condiciones. Han planteado opciones amarradas a un solo motor de Base de Datos, y eso es inaceptable.

2. En realidad si hay un trabajo más nuevo. La versión 7.0.1. En esta página puedes encontrarla :

http://zeosdownloads.firmos.at/downloads/snapshots/

3. Todos nos dicen que Zeos es muy bueno. Una vez estabilizado, como tenemos los fuentes, en el peor de los casos nosotros mismos podríamos corregir errores y agregar características. Lo primero ya nos tocó hacerlo y lo segundo parece que también porque hasta donde hemos mirado no está soportando parámetros BCD. Bueno, eso es una adelanto de los otros problemas que les dije que revisaremos mañana

[roman]

Je, je. Tienes razón en lo que acotas. Pero dime, ¿estás seguro de querer lanzar tu programa con una versión alpha? Es cierto, como dices, que al disponer del código fuente puedes tú mismo modificarlo, corregir errores; pero, los errores que has detectado, ¿serán todos? ¿No habrá por ahí una liebre que te salte en el momento menos esperado?

Quizá lo que habría que plantearse es el el uso de Lázarus como herramienta de desarrollo. Pero mejor no lo digo porque me vas a preguntar por alternativas

// Saludos

[rolandoj]

Empezado por roman

Je, je. Tienes razón en lo que acotas. Pero dime, ¿estás seguro de querer lanzar tu programa con una versión alpha? Es cierto, como dices, que al disponer del código fuente puedes tú mismo modificarlo, corregir errores; pero, los errores que has detectado, ¿serán todos? ¿No habrá por ahí una liebre que te salte en el momento menos esperado?

Quizá lo que habría que plantearse es el el uso de Lázarus como herramienta de desarrollo. Pero mejor no lo digo porque me vas a preguntar por alternativas

// Saludos

Hola Roman,

Ese es el punto delicado. Ciertamente, puede haber más errores, o limitaciones, y, honestamente, por lo que hemos visto hasta ahora, estamos esperando que haya varios más de importancia.

La ventaja que tenemos es que, por nuestra metodología, el uso de características no solo de Zeos, sino del propio Lazarus, es reducido.

Entre otras cosas, por lo mismo que anotas, es que no hemos considerado la posibilidad de usar Lazarus en el lado del cliente. En el lado del servidor, recuerda que nuestro desarrollo está es en Windows con Delphi. La idea de tenerlo en Linux es disponer de una alternativa atractiva a ciertos clientes. Esto de ahora es un trabajo exploratorio para nuestras opciones de largo plazo, no planeamos hacer la migración en este momento.

Por otro lado, estás planteando que Lazarus no es una herramienta confiable para desarrollos realmente serios de programación, y esa es una posición dura. Me gustaría si alguién pudiera orientarnos con algún enlace a donde se discuta el tema a fondo con gente que haya desarrollado algo realmente grande.

Nuestra opinión es cercana a la tuya en el sentido de que no es una herramienta suficientemente madura para un desarrollo serio por si misma. La falta de un muy buen depurador, y otras características que hemos visto, así nos lo hacen pensar.

Sin embargo, como la lógica la estamos desarrollando en Delphi, creemos viable pasarlo a Linux, sobre la Base de tener una capa de abstracción propia, de forma que el código nuestro tanto en Delphi como en Linux, excepto en ciertos casos especiales, sería siempre el mismo.

Ahora, tienes razón en que te voy a preguntar por alternativas. Tienes alguna viable ?. Ten en cuenta que pasar a otro lenguaje que no siga una sintaxis muy similar a Delphi sería muchísimo peor en términos de tiempo de desarrollo, ya que nosotros contamos con docenas de miles de líneas de código

[[mightydragonlor]]

Pues aplicaciones hechas con lazarus que conozca, estas:
http://www.peazip.org/index.html
http://code.google.com/p/transmisson-remote-gui/
http://forge.lazarusforum.de/projects/lazupdater/
seguro que hay muchos mas, pero estos son los que se me vienen a la mente xD

PD. se me olvidó esta galería http://wiki.lazarus.freepascal.org/L...cation_Gallery

[rolandoj]

Hola,

Muchísimas gracias por la información. Es un buen punto de referencia; pero, creo necesario anotar lo siguiente:

Por supuesto que hay programas hecho en Lazarus, y bastantes más que los mencionados; pero, yo me refería a sistemas realmente grandes, no a programas especializados. Me centro en grandes porque en un programa especializado hay mucho más margen para atender los inconvenientes.

Para ser claro, en nuestro caso, cuando hablo de un sistema grande me refiero a uno que integre simultaneamente muchas tecnologías y / o maneje grandes volumenes de datos, requiriendo multiples procesamientos de los mismos.

Nosotros manejamos mucho http, tanto en cliente como en el Web Server, correo electrónico, encriptación, compresión de datos, edición de documentos sgeuros con RTF, gráficas dinámicas (con TeeChar), muchísmo de Base de datos (ya nos acercamos a 500 tablas). estructuras de árbol, administración documental, algunos centenares de reportes impresos, incluyendo trabajar con formas preimpresa, etc.

Este tipo de desarrollo requiere una herramienta que permita depurar facilmente y que no haga perder tiempo obligando a cada rato a analizar código de terceros para corregir inconvenientes.

De las aplicaciones que listas, solo un par parecen acercarse algo a alguno de nuestros módulos; el resto son manejos muy especializados, que incluso, en su mayoría no usan Bases de Datos, o hacen un uso mínimo.

La pregunta importante es : alguién de este foro tiene experiencia programando este tipo de sistemas con lazarus ?.

Es que una cosa es la teoría y otra es la práctica; por eso quiero insistir en esta pregunta, y aclaro, no es con ánimo de molestar a nadie sino para valorar mejor la realidad del uso de Lazarus, para los propósitos mencionados, entre nuestra comunidad.

[[mightydragonlor]]

Para ello tienes que ir a brazil, hay muchos sistemas grandes que hacen lo que planteas, pero no son abiertos, lo del depurador es mentira, ya me cansé de que digan que es muy malo y demás, es un buen depurador y hace lo que se requiere, yo personalmente me he sentado a depurar, al inicio no encontraba nada, pero para encontrar hay que buscar, en el menú ver, ventanas de depuración, tienes lo básico para depurar bien, hilo que depuras, variables, histórico, ensamblador, puntos de interrupción y de observación, obviamente, no es comparable con el depurador que trae el VS2010 que me parece fabuloso, pero no la basura que suelen decir que es, synapse hasta donde sé es el mejor paquete de clases para manejo de http, ftp, https y demás protocolos, la encriptación con componentes DCrypt o por SHA1.pas que trae por defecto la LCL, el TChart está bastante completo y si es necesario presentar gráficas mas bonitas para eso dispones de AGG.Pas, el acceso a base de datos no hay nada como DBExpress excepto por Zeos, sin embargo todos los controles estandar de SQLDB pueden interactuar con cualquier componente de conexión de la misma paleta, así que esa implementación sería simple, por el lado de reportes no puedo decir nada, ya que no poseo experiencia con LazReport ni con FortressReport, Finalmente, como decimos por acá, "el mal trabajador siempre le hecha la culpa a la herramienta", un ejemplo de que lazarus sirve para mucho es FactuLinex, aunque las personas que se han encargado de portarlo de kilyx a lazarus tienen problemas de código spaggeti, FactuLinex funciona muy bien.

[rolandoj]

Hola,

Gracias por las anotaciones.

Si entiendo bien, implícitamente estás diciendo que posees experiencia con todo lo mencionado excepto con reportes. Eso es correcto ?

Ahora, también implícitamente, estás confirmando que no se tiene una solución del más alto nivel en el tema de acceso a Base de Datos.

Al respecto, y hasta donde hemos visto, un punto central es que el cubrimiento de múltiples motores de base de datos no es lo amplio que teníamos en el BDE o con dbExpress.

Y también en relación a eso, adelanto que uno de los dos problemas fuertes que mencioné antes y que quiero tratar en hilo aparte es precisamente otra característica que aparentemente no está implementada en Zeos y que es vital para nuestro manejo. Falta verificar si se trabajó en la última versión de Zeos. Creo que hoy pongo el hilo

Sobre el depurador integrado, nosotros no lo hemos probado porque cuando intentamos usarlo nos cierra Ubuntu en la máquina virtual. La causa ?, Según el log de errores es falta de memoria; un problema adminstrativo que estamos en espera de que se resuelva.

Sin embargo, como bien dices, lo que hemos leído no son buenos comentarios, ya que sugieren que se use un depurador externo. Aparte de eso, la revisión que hemos hecho del código fuente de CGI indica que aparentemente para depurar aplicativos Web hay que estar colocando a cada paso del código inserciones condicionales de código específico de depuración (Condicionales CGIdebug), lo cual nos hace pensar que no es nada facil depurar el servidor. Puedes confirmar eso ?. Has depurado aplicativos Web usando el depurador integrado ?. Que diferencia tiene con el disponible bajo Delphi ?

[[mightydragonlor]]

Hola, como bien dices, para Lazarus no hay un dbExpress o BDE, lo mas parecido es Zeos, que como bien dice Roman, el avance es casi nulo, pero una forma facíl de implementar esto (definiendo si basta con las conexiones de la pestaña SQLDB) es remplazar el TSQLConection por la necesitada, no es muy complicado de implementar por código, yo lo he hecho para MSSQL y Firebird, que son las que he necesitado, hasta el momento, ahora y lo mas complicado, lo que quieres es hacer un modulo CGI para Apache Lazarus no lo puede Depurar como lo hace Delphi o VS, el por que es simple, para Delphi y VS en tiempo de ejecución se genera un servidor en memoria por ellos mismos para atrapar todas las llamadas, pero en Lazarus esto nunca sucede, solo se genera el ejecutable y se pone en el servidor, una forma de detectar esos errores es esta http://wiki.lazarus.freepascal.org/A...L-Android_Appl, personalmente no me gusta y acá te dejo una pregunta, que necesidad hay específicamente para que sea un CGI? dependiendo de esto podríamos tener una alternativa a la necesidad.
Se me olvidaba el Debug Server, pero igual sigue sin gustarme.

[[rretamar]]

Voy a "Meter la cuchara":

Me da la sensación de que quieren sacarle provecho inmediato tanto a Lazarus como a Linux, intentando hacer las cosas de la misma manera en que se hacían en Windows (y el Delphi), y eso es un grave error porque son diferentes.

[[mightydragonlor]]

Tienes toda la razón compañero rretamar, por eso mismo creo que hay que mirar la necesidad, exactamente como necesidad, no como hasta ahora que es "hacer la misma implementación hecha en Delphi" sino mas bien algo como, es necesario que una aplicación cliente se comunique con una aplicación servidor por X protocolo y que devuelva X resultado, para lo último, yo sugiero un Servicio o Daemon, que use protocolos comoHttp, TCP o UPD, pero algo exactamente igual a lo hecho en Delphi muy dificilmente puede ser implementado en Lazarus.

[roman]

Pues yo no veo que este sea el caso. El compañero rolandoj ha dicho, por ejemplo:

Empezado por rolandoj

Nosotros manejamos mucho http, tanto en cliente como en el Web Server, correo electrónico, encriptación, compresión de datos, edición de documentos sgeuros con RTF, gráficas dinámicas (con TeeChar), muchísmo de Base de datos (ya nos acercamos a 500 tablas). estructuras de árbol, administración documental, algunos centenares de reportes impresos, incluyendo trabajar con formas preimpresa, etc.

es decir, está hablando de necesidades generales. ¿En dónde se vislumbra que quiera resolver todo de la misma manera que en Windows?

// Saludos

[[mightydragonlor]]

En necesitar hacerlo en CGI, solo por eso lo digo, en si a lo que me refiero es replantear el usar CGI por alguna otra alternativa..

[rolandoj]

Hola,

Gracias a todos por participar.

Aclaro la situación:

1. No hemos pensado desarrollar con CGI sino con módulos Apache. Empezamos las pruebas por CGI porque se suponía que era el modelo más sencillo de manejar. Nosotros en Windows usamos es ISAPI. Hasta donde tenemos conocimiento, para producción, el equivalente en Linux son los módulos Apache; y para allá es en últimas a donde vamos

2. La idea si es hacer las cosas lo más parecidas a Delphi posibles, por una razón muy sencilla: Nos es inviable, en términos de costos, tiempos y logística, pretender armar algo independiente.

3. Lo que queremos es montar una capa de abstracción que brinde servicios básicos, de tal forma que sea la única diferente entre ambas plataformas (con alguna que otra excepción, porque ya vimos que no podríamos hacerlo al 100%). Esa capa la tenemos montada en Windows porque nos preparamos desde un principio para soportar más de una plataforma. La idea es migrarla a Lazarus - Linux; de esa forma, una vez estabilizada, salvo casos excepcionales, podríamos mantenernos desarrollando un solo código para ambas plataformas.

[[geolife]]

Hola Rolando,

En cuanto a Zeos creo que las últimas versiones de trabajo ahora se encuentran aquí:http://zeoslib.svn.sourceforge.net/ -- cambiaron la ubicación, y parece que están por la revisión 932.

Por lo que he visto, creo que solo hay un desarrollador verdaderamente activo llamado markdaems que va manteniendo el código, pero ya ha comentado en alguna ocasión, que dada la tarea y recayendo en unas solas espaldas la cosa va lenta. Ellos están esperan como lluvia del cielo colaboradores para el proyecto, creo que si tenéis aportaciones al código lo mejor será contactar con ellos para ver si se pueden incorporar. Desde luego Zeos es un proyecto importante para Delphi y Lazarus.

Saludos!

Geolife



--------------

Empezado por rolandoj

Hola,

Gracias a todos por participar.

Aclaro la situación:

1. No hemos pensado desarrollar con CGI sino con módulos Apache. Empezamos las pruebas por CGI porque se suponía que era el modelo más sencillo de manejar. Nosotros en Windows usamos es ISAPI. Hasta donde tenemos conocimiento, para producción, el equivalente en Linux son los módulos Apache; y para allá es en últimas a donde vamos

2. La idea si es hacer las cosas lo más parecidas a Delphi posibles, por una razón muy sencilla: Nos es inviable, en términos de costos, tiempos y logística, pretender armar algo independiente.

3. Lo que queremos es montar una capa de abstracción que brinde servicios básicos, de tal forma que sea la única diferente entre ambas plataformas (con alguna que otra excepción, porque ya vimos que no podríamos hacerlo al 100%). Esa capa la tenemos montada en Windows porque nos preparamos desde un principio para soportar más de una plataforma. La idea es migrarla a Lazarus - Linux; de esa forma, una vez estabilizada, salvo casos excepcionales, podríamos mantenernos desarrollando un solo código para ambas plataformas.

[Casimiro Notevi]

Vaya, entonces ese es el problema, que el pobre está solo, sin ayuda. Resulta extraño dado la gran difusión que tienen esos componentes. Supongo que debería poner un un mensaje de aviso para encontrar personas que ayuden, porque en cualquier momento se cansa o se aburre y se acaba el proyecto.

[[geolife]]

Hola Casimiro!

Llevas toda la razón del mundo!

En algún mensaje de los foros a veces se le ha visto asediado y pidiendo amablemente cualquier colaboración. La verdad es que uno solo, puede quemarse fácilmente con un proyecto de esa envergadura. Y como tu dices, es extraño y una pena al mismo tiempo que con lo conocidos y utilizados que son estos componentes, no haya más mentes que le dediquen un poco de atención.

Hace no mucho, ha trasladado el desarrollo a SourceForge, aquí se puede ver los cambios que van realizando al código fuente y las aportaciones:
http://sourceforge.net/projects/zeoslib/develop