Chiara, una pregunta, vos necesitas las transacciones? Yo en una aplicación que mantiene todo en memoria porque es muy chiquita lo único que hice fue mantener en una global siempre una transacción sola, de esta manera me despreocupo bastante del tema persistencia, es mas, podes llegar a hacer los #markDirty en forma automática en Dolphin y VW (en este ultimo caso no recuerdo si era tan cómodo como en Dolphin). Si estás interesado en la técnica (que creo vos mismo podes implementar) avisame y cuando llego a casa te mando un ejemplo de como sería. Es algo muy limitado y me parece que no permite que varias imagenes accedan a la misma base de datos (no se si es tu caso).
Saludos GallegO Chiara escribió: > Hola, lista > > Lamentablemente sigo colgado con este tema :-(. No encuentro por > ningún lado algún tuto que me explique un poco mejor que lo que hay en > la web oficial (demasiado básico para mi gusto) y al ser la primera > vez que intento algo en omnibase estoy un tanto perdido. > > Mi mayor problema es con ela metodología de trabajo de transacciones. > > Para explicar un poquito más, lo que yo tengo es una plicación > distribuida con opentalk (aunque funciona como cliente servidor, donde > los clientes solo tienen las vistas). Estas vistas de los objetos > deberían ser consistentes y mantenerse consistentes a los cambios. En > memoria me funciona todo perfecto, pero a la hora de intentar > persistir con Omnibase tengo un pequeño problema que es que los > objetos persistidos no escapan a las transacciones. > > Una de las cosas que había pensado es desarrollar una especie de proxi > [*] que conozca el OID de cada instancia lebantada en memoria (este > proxi sería único por instancia) y que sepa como persistir el objeto > (simulando un markDirty pero afuera de una transacción). De esta > manera, las vistas se montarían sobre los proxis y con eso > "arreglaría" las cosas. > > [*]no sería proxi completo pues cachearía los datos para las lecturas, > solo redirigiría las escrituras y se "actualizaría" en base a estas > escrituras. El problema de esto es que si quisiera hacer un proxi > completamente genérico, redirigiría las lecturas a la BD con lo que la > performance decaería demasiado, y si no hago uno genérico, tendría que > implementar el proxi para cada clase persistente (cosa que no quiero > :-() > > Agradecería terriblemente si alguien me podría tirar algunos tips, y > si tienen tutoriales mejor :-) > > On 10/31/06, Esteban A. Maringolo <[EMAIL PROTECTED]> wrote: >> On 10/31/06, Chiara <[EMAIL PROTECTED]> wrote: >>> Hola, estuve viendo las discuciones previas pero me siguen quedando >>> muchas cosas en el aire :-( (Me faltaría un buen tuto) >>> >>>> Se que en la lista hay alguien que tiene una aplicacion de >>>> demostracion, que creo te sera muy util. >>> Si alguien me la manda sera muy agradecido :-) >>> >>>> Para metodologia de desarrollo, ahi te voy a poder ayudar mas. >>> :-) Mas que nada es el como manejar los clusters, cuando conviene >>> guardar todo como un cluster y cuando no. >> Te conviene guardar como cluster (con id) cuando necesitas preservar >> la identidad del objeto (y por consiguiente sus relaciones). >> >> Si un objeto tiene, por ej, items, que no son referenciados por otros >> objetos, te conviene que estos se serialicen sin ser persistidos con >> un odb identifier. >> >> Saludos. >> >> -- >> Esteban A. Maringolo >> [EMAIL PROTECTED] > --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups-beta.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
