Esteban,
>Osea... si uno tiene un manager de objetos, por ej, de personas, ese
>manager trae sus elementos de una lectura de la BD, en una
>transacción, si uno quiere editar alguno de esos, ¿abre otra
>transacción, sigue dentro de la misma?. Pero bueno, eso tiene que ver
>con técnicas de trabajo.
>
Levantas los objetos en una transaccion y los editas en la misma.
Cuando confirmas los cambios das #commit o #checkpoint (que no libera los
locks en los objetos).
Podes tener asociado un tipo de presenter con una Session asociada, y es
la session a quien le pedis los objetos.
Cuando editas algun objeto los haces sobre la misma Session. Cuando se cierra
el presenter confirmas o abortas la Session.
Session puede ser una clase abstracta cuyas subclases sean ImageSession,
PersistentSession, OmniBaseSession, ReStoreSession, etc.
Esta jerarquia puede trabajar en paralelo con una jerarquia Server con la
mismas subclases, asi el trabajo se facilita mucho.
La unica diferencia de pasar de una BD a OmniBase (o viceversa) es el
#markDirty,
que ReStore lo hace automaticamente (con su costo claro) y OmniBase no. Pero
el #markDirty lo pongo en una jerarquia de conectores especiales.
Por lo que:
OmniBaseSession
markDirty: anObject
^transaction markDirty: anObject
ReStoreSession
markDirty: anObject
^anObject
Con cualquier tipo de persistencia no tenes que cambiar nada, la unica
desventaja
son los TestCase, que algun momento (con OmniBase) deben recibir el #markDirty.
El modelo ni se entera del #markDirty.
Saludos Bruno
