Hi n8gray,
The system you outline seems reasonable too. I'm not sure there's much value
in splitting out GameState and GameMeta, but otherwise they seem reasonable.
My main concern behind not having a separate GamePlayer entity would be a
profusion of ListProperties for per-player data, but if
Hi n8gray,
Excellent question!
Given the amount of information you're likely to store against Players2Games
(GamePlayers, perhaps?), and the number of games any one player may have,
and the likely access patterns, I would suggest sticking with a separate
model for it.
The main lesson for using
On Jun 10, 5:21 pm, Tony fatd...@gmail.com wrote:
The biggest question I wished I'd asked myself before designing my app
is: what sorts of models will I want to update together in
transactions? Because in Datastore you can only run transactions on
entities in the same entity group (meaning
Hi Nick,
On Jun 11, 4:19 am, Nick Johnson (Google) nick.john...@google.com
wrote:
Hi n8gray,
Excellent question!
Given the amount of information you're likely to store against Players2Games
(GamePlayers, perhaps?), and the number of games any one player may have,
and the likely access
It's a really good question and perhaps someone with more db
experience than me will write some kind of tutorial about planning
your db structure for GAE...
The biggest question I wished I'd asked myself before designing my app
is: what sorts of models will I want to update together in