Me hace ruido lo de AtomicComposite, me suena a "blanco negruzco" :-)
Pero es una cuestión de comprensión y de heredar el nombre seguramente
desde Dolphin 4.
AtomicComposite es por que guarda un objeto atomico. unPaciente,
unaInternacion, etc.
PacienteComposite
InternacionComposite
Los composite de altas y bajas son listas que editan objetos usando el
EdditingObjectPresenter.
El EdditingObjectPresenter manipula a cualquier AtomicComposite para
mpdificarlo.
¿Equivaldrían a los AspectAdaptors pero marcando el markDirty cuando
algo se "setea" mediante ellos?
Si. Una jerarquia de conectores que trabaja de otra forma.
Aca no entiendo.
Osea... ¿cuando testeas lo haces con objetos "ya persistidos" o
asumiendo que la persistencia es transparente?
Asumo que los Test que cambian objetos (y habria que mandarle el
#markDirty) tambien los van a cambiar sobre la OmniBase, la unica
diferencia es el #markDirty. Por lo que no me interesa ejecutar esos
mismo test sobre la OmniBase, hay que estudiar las excepciones.
Ademas se pueden hacer test especiales para la OmniBase, ReStore, etc.
¿Y marca dirty todo, o sólo el cluster principal?
Solo el objeto modificado, el cluster en cuestion.
Esta session le pertence al un presenter mas general alguna subclase de
SeesionComposite.
El EdditingObjectPresenter se crea con una session adentro.
Lo crea por ejemplo SURPacienteComposite (search update remove).
Al objeto seleccionado en SURPacienteComposite lo quiero editar -->
abro un EdditingObjectPresenter con la session del SUR....
Esto me hace inferir, tal vez ingenuamente, que el ODBTree lo tenes
con clave por cada clase, y luego el modelo navegable, de manera de
acceder a las instancias de las clases directamente y luego comenzar a
traer todo a partir de allí.
Si. Todas las clases persistentes tiene una key en el root principal con
sus instancias.
Pero el el root tambien estan los BTree que representan indices.
Saludos Bruno
