GAE goodness and badness

GAE’s inherent logging facilities are pretty good and easily brought a couple of bugs in my prototype to my attention. That’s the goodness.

The badness is that GAE’s datastore doesn’t appear to have any sort of inherint journaling or rollback features, so if something gets funky in the data there aren’t any breadcrumbs to follow to get a clue as to how it got that way, nor is there a way to rollback to the last known good state. Even bulk downloading and uploading of data isn’t inherently supported to try to do just a straight off-site backup of a good state and then a restore of that state from the off-site backup. Using a standard hosting a site, at a minimum you could occasionally backup your SQLite file right on the server and just replace it if things got wonky. Obviously SQLite doesn’t scale very far. Other SQL DBs have their scalability limites as well. So it looks likes its either write your data distribution code or write your own journaling and rollback code. GAE’s datastore and API also don’t appear to allow modifications of the existing schema either. If you add a field to an entity in the code when you try to load an existing entity it will fail, so you can really only make additions.

I’ll think I’ll still forge ahead with GAE for my first web browser based strategy game just for the experience, but I’m definitely feeling more motivated to go back and work on the distributed app platform I’ve been wanting to work on.

Advertisements
This entry was posted in Game Development, Web development and tagged , , , . Bookmark the permalink.

Have something to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s