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

[rolandoj]

Empezado por Casimiro Notevi

Un buen depurador es algo que todavía está pendiente, el GDB funciona bien, aunque he oído comentarios de que a algunos no les funciona como debería, en las pruebas que he hecho yo, la verdad, va bastante bien. Aunque también es cierto que no hay comparación con el de delphi.

Hola,

Muchas gracias por la información.

Eso confirma lo que, en base a lo hasta ahora leído, nos temíamos.

En el fondo, es el verdadero problema para la escasez de desarrollos realmente grandes con Lazarus. Un sistema como el nuestro, con docenas de miles de líneas de código, aunque no es imposible, es una locura intentar hacerlo sin un muy buen depurador.

Nuestro enfoque es por ende en dos etapas:

1. Usar Linux como Front-end. Eso, aunque faltaría probar alguito más, y luego dar tiempo de funcionamiento a ver la estabilidad, es algo que creo que ya tenemos bajo control.

2. Poner nuestro servidor en Lazarus/Linux. Aquí estamos avanzando; pero, aún en lo más básico.

Nuestra estrategia es encapsular la funcionalidad de Base de Datos, del Web Module, y alguna que otra complementaria, en nuestra propia capa de abstracción; de tal forma que podamos tener portabilidad Delphi-Lazarus; así mantener ek desarrollo de todo el código propio (bueno, excepto la capa de abstracción), en Delphi, y en Lazarus tan solo hacer alguno que otro ajuste muy mínimo que pudiera ocurrir.

Por cierto, has usado ese depurador con una aplicación de Módulo Apache, o al menos una CGI ?. Es que es ahí donde tenemos nosotros que trabajar y, según leímos, la depuración multihilos anda mal; así que en últimas la alternativa sería depurar el CGI.

Una última pregunta. Yo supongo que el problema de tener un buen depurador integrado se debe haber discutido a fondo en los foros de alto nivel de Lazarus. Y también supongoo que su no implementación se debe a un alto nivel de dificultad. Tienes alguna dirección donde se esté haciendo seguimiento al tema ?. Digo, para estar al tanto de las perpectivas.

[Casimiro Noteví]

Empezado por rolandoj

Por cierto, has usado ese depurador con una aplicación de Módulo Apache, o al menos una CGI ?

No, sólo lo he usado con componentes "normales" y de bases de datos.

[rolandoj]

Hola,

Bueno, hoy logramos progresar. Vamos por partes:

1. Tras superar varios problemas, reinstalamos todo y quedamos con la siguiente combinación: Ubuntu 11.04 Naty + Apache 2.2 + Firebird 2.5 + Zeos 7.0.0

2. Un problema fue que en lugar de instalar solo Lazarus, intentamos instalar CodePython; pero, no pudimos. Aunque aparentemente había instalado bien, las cosas no trabajan. Intentamos arreglarlo; pero, como nos hizo perder mucho tiempo optamos por trabajar solo con Lazarus

3. Al repetir la prueba, volvió a fallar. Para ser exactos, el error fué :

Operation is not alloewed in FORWARD ONLY mode

4. Entonces intentamos usando TZQuery en lugar de TZReadOnlyQuery y ahí si funcionó !!

5. La conclusión es la siguiente : TZReadOnlyQuery está optimizado para lo que sería el uso normal de un Query. En esa optimización, debe estar empleando una instrucción que no es soportada en el modo optimizado FORWARD ONLY. Cual instrucción ?. Una busqueda rápida indica que el mensaje es propio de Zeos y està definido en la unidad ZMessages. En Google hay un solo reporte del mismo; pero, bajo otras condiciones. Hoy no nos alcanzó el tiempo; pero, intentaremos ubicarla mañana porque, aunque TZQuery ya nos abre una puerta, en teoría nosotros deberíamos utilizar es TZReadOnlyQuery

6. Aunque es un avance, de todas formas toca probar bastante más. Vamos a ver.

[Casimiro Noteví]

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.

[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 Noteví]

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