3

Context: I'm working on an HTML 5 game without persisted state. Every time you refresh the page, you start at the beginning. People are requesting that they can start where they left off if they leave the page. I plan to implement this as Local Storage. The thing that makes apprehensive about this is a new kind of bug I'll have to consider: If you come back and there's a newer code, it may not be able to deserialize the storage.

As an example, the state when serialized may have looked like this:

{
  foo: "bar"
}

But when the player tries the game next month, that field doesn't even exist anymore and has been broken up into two fields with a completely different type.

This is bound to happen, and I think I know how to fix this: I'll put a version number in the data, and when I release version y of the app, I'll have to write code to migrate from version x state to version y state. If I release version z of the app, I'll have to write code to migrate from version y to version z. I'll probably call this logic after deserialization.

But that's not what this question is about (although if there's a flaw in my approach, I'd want to hear it). What I want to know is: How do I automate something (possibly a test) that tells me when I need to write a migration script and when I need to change the data's version number?

I feel automation is the key here, because things will go very wrong if I make a mistake and remembering to change a version number / write a migration script will be the last thing on my mind when I just finished that shiny new feature I want others to see.


An interesting (but perhaps irrelevant) realization: All these issues go away if I store the data on my server in a database with a schema. That lets me confidently know that all the data is in the right state (if my schema is good). The problem with persisting locally is I lose control of the data and when it gets migrated.


This question is similar but different to this one. The difference is I'm concerned primarily with automation and s/he's not and we're using different languages (seeing how the accepted answer is a Java library, that makes it irrelevant to me).

  • 1
    Maybe add a commit hook to your version control that checks if any code related to serialization has been updated and if so pauses the commit with a prompt asking if you've double-checked the schema? Trying to automatically determine if a change to those files implies a schema change is probably far more trouble than it's worth, especially since your schema shouldn't change too often. A simple poka-yoke to make sure you don't forget to take care of things manually would be cheap though. – Doval Jul 7 '14 at 17:25
4

How do I automate something (possibly a test) that tells me when I need to write a migration script and when I need to change the data's version number?

When your automated unit tests fail while importing old data into a newer model, that's one very clear indicator that you need to write a migration script/process.

4

Every time you make a code change that touches your serialization, you must add a new test case in your automated test suite that uses the new fields, or reads the old fields, etc. Over time you'll accumulate more and more coverage for your version transitions. As long as you run your test suite whenever you make changes you'll get notified when you stop being able to read something that used to work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.