feat: Cbor restart file - #2596
Conversation
ec36e54 to
c7aba69
Compare
trisyoungs
left a comment
trisyoungs
left a comment
There was a problem hiding this comment.
The intent here is good, I think, but it brings up a discussion regarding the data sources we need to serialise into a node restart file (incidentally, I think we should move away from calling this data "restart" data, and think about it just in terms of "data the node needs to save to ensure its state").
What you have here focuses quite rightly on the core member variable data of Configuration - although the finished product needs Molecule-centred information rather than Atomic data which brings its own complications. This data isn't calculated per se - it's inherent to the object. Other nodes specifically calculate data - this is already captured to a large degree with the addSerialisable(), serialiseData() and deserialiseData() functions, so to generate a full restart state packet for a node in general both the inner and "calculated" data must be written.
| std::vector<ConfigurationAtom> after = configNode->configuration().atoms(); | ||
|
|
||
| auto getR = [](const auto x) { return x.r(); }; | ||
| EXPECT_TRUE(std::ranges::equal(before | std::views::transform(getR), after | std::views::transform(getR))); |
There was a problem hiding this comment.
This is a lovely little construction!
2 participants
This PR puts in the framework for saving and loading restart files/directories. Nodes can overload virtual functions to save information to a restart file (which is named after the Node).
Currently, only the state of the configuration is saved, but other nodes will likely need restart information as well. Also, there's a larger question about when to save and/or load restart files. I suspect that it will need to go into IteratorGraph, but there are still some questions about how loading will work.