Flexible Persistence (Or: More PCType Woes)

Note to self: when designing a persistence mechanism for an application, make the underpinnings as flexible as possible. If the container doesn't impose any restrictions (Relational database, I'm looking at you), then don't arbitrarily create them.

Many of the Fall of Rome rules definitions are persisted to a flat file. There are several methods that talk to an Archive, asking it to load and store items into the flat file. To make the developer's life easier, the API allows me to ask for an int when I know it's an int, and ask for a String if I know the data type is a string. Unfortunately, the items written and read from the underlying file also encode the type of data. This makes life extremely compilicated when trying to change from a char (the old PopCenterType encoding) and a String (much handier for new pop center types, like Small Towns).

If I want to change how PopCenterTypes are archived, I shall have to hand edit every existing file where they are archived, introduce some method of changing them within the code itself, or altering the underlying persistence mechanism to be type agnostic. All three of these methods will require hand editing the files where the information is stored (and it's duplicated in several places - the master rules file and each individual game turn file).

I believe it will be possible to solve this by attempting to read items the new way, failing, and defaulting to the old way. That's a messy solution to a problem that never had to exist. The rules are stored in flat files. Flat files store bytes with no concept of data type. Lets store everything as a String. Strings can be manipulated to whatever is required by the internal application. It might not be as performant, but for a game where each turn is run every three days, adding an extra couple cycles to the loading time to improve developer flexibility seems like a fair trade.