Container for checkpoint models, access to deployed/available models.
{@link CheckpointVault} is one per model and populates single
ModelCheckpoints object with persisted
state of checkpoints for the given model (model identified with
ModelStreamManager.
Unlike
ModelCheckpoints, this is focused on checkpoint SModel persistence, rather than
API suited for reference resolution.
Since it is a vault for all CPs of a given model, map model-to-ModelCheckpoints is kept elsewhere (now
CrossModelEnvironment)
XXX ideas:
read models into no module/repo here, populate ModelCheckpoints object (no need to obtain read access!)
then, once checkpoints are needed, they get exposed in new transient module (with name that resembles name
of the original module, just in case anyone needs it?).
1. Multiple plans with few CPs per model - how to persist.
2. When to persist? TextGenToMemory shall not serialize it, while regular TextGen shall.
Both shall read CPs if available
3. How to manage removal of CPs/stale CPs?
4. --
5. Files: checkpoints [1] + planName-cpName.mps [*], former lists all known .mps files with cp models.
What about conflicts? Another file extension? UUID file names? On one hand, don't need them human-readable
OTOH, when it's easy to recognize where file belongs is nice
6. Do I need to reconstruct ModelCheckpoints in RT, without serializing the registry)? Perhaps, I don't need to
keep identity of checkpoint and plan inside a model (now with facilities of ModelWithAttributes)
7. What about consistency of plan and its persisted cp models? What if Plan is expected to have CP1 and CP2, but locally
we've got CP1 and CP3? How do we check consistency, how do we react to inconsistency.
Pretty much similar to
ExportsVault and conceptually to
ModelVault, perhaps
a shared superclass worth adding. The difference is that both aforementioned vaults deal with
single associated stream/model, while here we need to deal with multiple checkpoint models.