![(please configure the [header_logo] section in trac.ini)](/mms/chrome/site/logomms.png)
Opened 14 years ago
Closed 14 years ago
#568 closed doubt (fixed)
Incoherencia entre los repositorios y el contenedor de MMS
| Reported by: | imendez | Owned by: | Pedro Gea |
|---|---|---|---|
| Priority: | critical | Milestone: | Release 0.6 |
| Component: | General | Keywords: | |
| Cc: | atorre@… |
Description
Hola, supongo que es por desconocimiento, pero la relación entre los repositorios y el contenedor de MMS me parece muy poco intuitiva.
Si no me equivoco, los repositorios están dentro del Container, pero si esto es así no entiendo cosas como que:
- MMS::Container::FindDataSet sólo devuelva cierto si el DataSet está cargado en memoria local. Es decir, si tengo un DataSet en un repositorio, y éste está dentro del Container, ¿no debería encontrarlo?
- Al hacer "Eliminar todas las estimaciones" en el interfaz de MMS desde el directorio raíz "Contenedor de MMS" borre "sólo" las estimaciones que tiene en memoria, y no borre las que hay en los repositorios.
¿No sería más lógico que las diferentes "cajas" (DataSets, Modelos, Estimaciones, Previsiones, Combinaciones y Ajustes) que cuelgan actualmente del Container pasaran a depender de un objeto intermedio, digamos "Memoria Local"?
Es decir, algo tipo:
- Container:
- Repositorios:
- Default
- Local
- Etc.
- "Memoria Local"
- DataSets
- Modelos
- Estimaciones
- Etc.
- Repositorios:
Ya sé que es una cuestión de nomenclatura, y que todos nos hemos acostumbrado ya a trabajar así, pero la verdad es que cuando hago "Eliminar todas las estimaciones" me recorre un escalofrío desde los pies hasta las orejas, y me dan ganas de hacer un back-up del disco duro por si acaso... ;-)
En fin, lo dejo como duda.
Change History (4)
comment:1 Changed 14 years ago by
| Status: | new → accepted |
|---|
comment:2 Changed 14 years ago by
| Priority: | major → critical |
|---|
Se sugiere crear un objeto MMS::Network que maneje las conexiones y repositorios de MMS y que actualmente hace el contenedor principal MMS::Container.
Provisionalmente se podría mantener por compatibilidad el uso de las llamadas MMS::Container::GetRepository(...) y similares. Hasta que se extienda el uso de MMS::Network::GetRepository(...).
comment:3 Changed 14 years ago by
comment:4 Changed 14 years ago by
| Milestone: | → Release 0.6 |
|---|---|
| Resolution: | → fixed |
| Status: | accepted → closed |
La estructura final difiere de la propuesta:
- Container:
- Repositorios:
- Default
- Local
- Etc.
- Memoria Local"
- DataSets
- Modelos
- Estimaciones
- Etc.
- Repositorios:
sobre todo para mantener la mayor parte de las llamadas actuales.
La estructura implementada queda:
- Network
- Default
- Local
- Etc.
- Container
- DataSets
- Modelos
- Estimaciones
- Etc.
La verdad es que es una buena crítica.
Probablemente los repositoriorios no deberían presentarse a ese nivel, pues no están dentro del contenedor de MMS en el sentido en el que indicas.
Que se muestren así es en parte por antiguas limitaciones en el diseño de MMS que quizá podrían ya reconsiderarse.
Creo que la mejor manera de entender estos dos tipos de objetos es considerarlos como dos variantes de un tipo contenedor más general:
Los mecanismos de carga y guardado de un objeto se pueden ver como mecanismos de comunicación entre el contenedor en RAM (MMS::Container) y los repositorios (contenedores en disco duro).
Nótese que ambos tipos de contenedores presentan métodos similares.
La estructura conceptual sería algo como:
Para que no quepa duda, los métodos eliminar del contenedor principal (MMS::Container) no tocan a los repositorios para nada. De hecho en los repositorios aún no me atreví a poner métodos Remove[Objects] (en plural) y sólo encontrarás, por ejemplo, un método RemoveEstimation.