Serialization with databases
Posted: Wed Jul 22, 2020 2:51 pm
There are a lot of interrelated issues here which can get resolved with just a few relativly simple mechanisms in principle.
a) Serialization: Marshalling and Unmarshalling . Currently each script is responsible for the marshalling of its data.
A script may register fields for automated Serialization. The engine is supposed to be responsible for the Serialization of the registered fields when loading/storing saves. This should remove and prevent some bugs by design.
Advantage: prevents class of bugs by design
Advantage: transition can happen gradually because old serialization code can still be supported in parallel
Disadvantage: huge refactoring
b) storage with event store: A lot of information can be stored with a event store. This makes sense for the log and maybe cargo etc.
Advantage: prevents a class of bugs by design.
Advantage: data stays in savegame except when everything gets projected.
Disadvantage: huge refactoring?
I would suggest sqlite as a backend of the event store, the automated serialization can get stored as json.
a) Serialization: Marshalling and Unmarshalling . Currently each script is responsible for the marshalling of its data.
A script may register fields for automated Serialization. The engine is supposed to be responsible for the Serialization of the registered fields when loading/storing saves. This should remove and prevent some bugs by design.
Advantage: prevents class of bugs by design
Advantage: transition can happen gradually because old serialization code can still be supported in parallel
Disadvantage: huge refactoring
b) storage with event store: A lot of information can be stored with a event store. This makes sense for the log and maybe cargo etc.
Advantage: prevents a class of bugs by design.
Advantage: data stays in savegame except when everything gets projected.
Disadvantage: huge refactoring?
I would suggest sqlite as a backend of the event store, the automated serialization can get stored as json.