Granite Data Services 1.0.0

1. Roy 13.04.08 / 9pm

   Carlos,

   ¿sabes dónde puedo encontrar documentación para la integración de Gravity-Hibernate-Flex ? He trabajado un buen tiempo con Hibernate (integrado con JSF/JSP) y estoy explorando Flex para un nuevo proyecto no menor!

   Como todo el mundo, tengo problema con LazyInitializationException (es ridículo pensar en la opción lazy-false)… y no he encontrado soluciones adecuadas y robustas con BlazeDS ni LiveCycle DS.

   Entiendo que Gravity tiene este tema resuelto… pero en la propia documentación de Gravity no encuentro mucho de su integración con hibernate.

   Desde ya te agradezco por la información!
2. Carlos Rovira 14.04.08 / 10am

   Hola Roy,

   Gravity no tiene resuelto este tema. Granite tiene un sistema basado en manejar la serialización y deserialización de los VO hasta el cliente con los externalizers. Pero este tema no tiene que ver con Gravity. De hecho parece que gravity no termina de estar del todo maduro.

   Por otra parte, no es tan ridículo el desestimar el uso de lazy en arquitecturas RIA. Ten en cuenta que el manejo de las entidades lo estás haciendo en remoto desde cliente y tienes un montón de posibilidades. En arquitecturas tradicionales, el manejo de lazy estaba más acoplado a la capa del middleware y cobraba mayor sentido.

   Quizá este sea uno de esos casos en los que tenemos que replantearnos el uso y metodos tradicionales y ver si tienen sentido en las nuevas arquitecturas RIA.

   Sea como sea, todavía queda encontrar una solución “oficial” y que los distintos productos (BlazeDS, GraniteDS, LCDS, etc…) la implementen…
3. Roy 14.04.08 / 2pm

   Gracias Carlos por tu respuesta…

   El error fue mío: escribí “gravity” cuando estaba pensando en Granite! Tienes algo de Granite, externalizers e Hibernate?

   > “Por otra parte, no es tan ridículo el desestimar el uso de lazy en arquitecturas RIA….”

   No sé si estamos hablando de lo mismo, pero yo pienso que el uso de LAZY es fundamental (lazy=true) y mi problema (como el de todos) tiene que ver con no correr el riesgo de cargar la base entera con un simple “FROM Algo” (lazy=false), cuando yo sólo necesito una lista de “Algo”…

   > “Quizá este sea uno de esos casos en los que tenemos que replantearnos el uso y metodos tradicionales y ver si tienen sentido en las nuevas arquitecturas RIA.”

   Estoy contigo en esto… la arquitectura RIA no se compara con las tradicionales (típicos Request-Response) y corremos el riesgo de intentar seguir trabajando de la misma forma!

   >”Sea como sea, todavía queda encontrar una solución “oficial” y que los distintos productos (BlazeDS, GraniteDS, LCDS, etc…) la implementen…”

   Ojalá que pronto! Bye…
4. Carlos Rovira 14.04.08 / 5pm

   Efectivamente, hablamos de lo mismo. Hay un debate abierto actualmente acerca de ese tipo de automatismo desde el cliente. De hecho el “cargar la base entera” no tiene por que darse ya que la mayoría de motores te permiten configurar el numero de niveles que quieres traerte. Por tanto puedes hacer que el motor de persistencia solo traiga un nivel y el resto de extracciones se realicen en base a una lógica controlada de tu aplicación. Como te decía, los automatismos en este aspecto son bastante complejos y hasta cierto punto un poco naturales ya que estamos haciendo un lazy remoto que puede llevarnos a inconsistencias en la aplicación que no se daban cuando esa logica estaba entre el middleware y la base de datos.

Entradas RSS Ofertas RSS Comentarios RSS Registrarse Identificarse

Todo el contenido de madeinflex.com se publica bajo licencia Creative Commons.