Forum ‹ BigDB ‹ Best practices for data evolution over time?

[jasonMcIntosh]

I'm curious how others are approaching the problem of data evolution.

For example, say you have v1.0 of your game with a certain data structure, and then by v1.5 you have changed how some objects are represented and stored in BigDB (you might have added or removed properties or changed property data types, for example).

How do you handle migrating players to new or updated data structures over time?

Should we add some special case code for each version which detects old data and re-save() in the newer structures? Or would it be better to close the game, do a mass-conversion, and then reopen the game knowing that everything has been updated?

Are there any code patterns discovered or tools created to make this simpler?

Discuss!

[cjcenizal]

This is a really good question.

I think the mass-conversion would be the cleanest way to do it, but I haven't done this yet so I don't know how easy/difficult this will be to do using the PlayerIO API. If you update data structures on a case-by-case basis (e.g. in your game code once a player logs in), you will probably bloat your game code and fragment your players' data into many different representation versions.

Any thoughts from the PlayerIO staff?

[Henrik]

I would say add properties, and make special cases in your game to handle older versions so that you migrate users to the new data structure on a user-by-user basis. Doing a mass-migration on a live data-set is pretty risky, you're not gonna cover all users, so you have to have game code that handle multiple versions anyway.

I understand the appeal of having a "clean" database, but one property of BigDB is that you don't have an enforced schema, you just have objects with stuff on them, so you don't have to have the same layout for all objects as you would in an SQL database.

[cjcenizal]

I would take the game down for the mass-migration, otherwise there'd be no point.

It seems like such a headache to me to have to write special case after special case. When testing a new rollout, you'd have to test your special-case-handling code with every prior version to make sure you're not breaking anything! So you have to maintain test data in every prior schema.

Also, imagine having a DB with 5 different data representation versions. If someone with v5 interacts with a v1 player and something breaks, you'd need to identify the versions which don't play well together, which can only be done by adding version numbers to your DatabaseObjects. Not a big deal, but one more thing to maintain and worry about.

And heaven forbid you accidentally release live code with an error in your special-case-handling code. Now player data is potentially lost or corrupted, and possibly irrecoverable.

I understand BigDB's strength of offering a non-enforced schema. It makes BigDB a PLEASURE to work with, and one of the reasons I find PlayerIO such an attractive service. But is it possible to enforce a schema if desired? Are mass-migrations possible?

[jasonMcIntosh]

When testing a new rollout, you'd have to test your special-case-handling code with every prior version to make sure you're not breaking anything!

Good point. It seems like this could become confusing and bug-prone over time.

Henrik, do you see an issue with that? How would you deal with it?

Are mass-migrations possible?

In that case, I would probably have a special admin client command to trigger a conversion when you could guarantee that all players are offline (and keep them that way). Then walk through all relevant objects and update them (ie, load, remove fields, add new/altered fields, save, get next object, etc).

I guess the alternative is to export the whole database, process it offline, and then import to the live database? I'm not sure the details or if that's possible.

I'd love to hear more thoughts from Henrik and others about the pros and cons of this or other methods. Being experts on the PlayerIO systems, they surely see things I can't.

[Henrik]

If someone with v5 interacts with a v1 player and something breaks, you'd need to identify the versions which don't play well together

No no, that's not how you do it. When a player connects, you check the version of the data stored for him, and if it's old, you migrate that player then and there to the new format, and then he can continue playing. That way you only need to handle various versions of data in one place, not all over your game.

[cjcenizal]

Yes, I understand, Henrik. I'm building an asynchronous game where online players can interact with the data of players who are offline. It doesn't seem safe to allow a player to update the data format of another player, which is why I assumed the case of a V5 interacting with a V1's data. Do you see what I mean? Is this a reasonable problem?

[Henrik]

It doesn't seem safe to allow a player to update the data format of another player

Why not? You'll do it in server-side code anyway, and what's the difference if the migration is started because of something the owning player does, or something some other player does? With proper encapsulation you wouldn't know the difference anyway.

BigDB supports optimistic locking, so you can make the migration threadsafe by making sure the migration is only run once, so that's not a problem either.

[cjcenizal]

Thanks for your help, Henrik. It looks like I need to look into server-side manipulation of data more carefully. I have actually been doing all of my requests for data from the client.

I am still going to stick with the mass-migration route, unless testing proves it to be a bad idea. I don't want to build a system which relies upon a foundation of special cases.

[Henrik]

Thanks for your help, Henrik. It looks like I need to look into server-side manipulation of data more carefully. I have actually been doing all of my requests for data from the client.

Well, you can do the migration from the client as well, it doesn't really matter.

The reason you shouldn't do data manipulation from the client is that it means that players can make a rogue client that changes data to cheat in the game. If you do all your data manipulation from server-side, players can't cheat.

I am still going to stick with the mass-migration route, unless testing proves it to be a bad idea. I don't want to build a system which relies upon a foundation of special cases.

It'll work perfectly for small amount of players, it's when you have millions of players that it's not going to work very well, at least if it means noone can play the game while you're doing the migration.

[cjcenizal]

Gotcha. Thanks a lot, Henrik, I really appreciate your help.

[jasonMcIntosh]

Cheers, Henrik! Thanks for taking the time to give more of your thoughts on the issue.

I am going to explore both methods and see what comes out the other side.

And good luck, cjcenizal! Please let us know how things turn out for you. The more we can discuss and share experiences, the more we'll all know.

(P.S. I treat client-side as "read only" in regard to the BigDB. All of my db writes are server-side only. The client only responds to server responses to client requests so that the server is 99% authoritative. But I don't have any physics or action gameplay, so it's quite a bit simpler.)

[cjcenizal]

Thanks Jason! I'll let you know how it goes. I'm in the same camp as you and Henrik when it comes to security and server-side write authority. I'm still in the "making it fun" phase of game dev though, so I decided to give the client control over that stuff for now for the sake of faster development. I might be shooting myself in the foot for when I migrate control to the server though... oh well, we'll see.

[jasonMcIntosh]

I might be shooting myself in the foot for when I migrate control to the server though... oh well, we'll see.

If you have time constraints, that might be a problem.

But if you are not on a strict schedule, you might actually end up with better server code if you implement the "first draft" on the client. I usually end up with a better result the second time I implement a system because I understand it much better by then.

[FulaFisken]

I think adding new / updating properties on the fly is the best approach. We use the same initialization code for new players and old players. We always check for inconsistencies and correct values or add missing properties in the player init function. But I really don't see a point in removing old properties unless you really have to.