title: App Engine entity groups: grouping all of a user's data vs avoiding them as long as possible
body: <p>I'm working on a web application that allows users to create simple websites and publish them on a static web host, and I have problems deciding if and how I should use ancestors in the gray area between necessary and avoidable.</p>
  
  <p>The model is rather simple: currently every <code>User</code> has one or more <code>Website</code> entities. The <code>Website</code> entities store all the basic information about a website, plus it's nested navigation menu that refers to <code>Page</code> entities (the navigation tree is stored as a JSON property). The <code>Page</code> entity types are based on a PolyModel, and there are several page types that behave differently (There's a <code>GalleryPage</code>, for example).</p>
  
  <p>There are no entity groups (or rather, no entities with ancestors) as of yet, and I'll only need a couple of transactions. When updating a Page's name, for example, I have to update it in the <code>Page</code> entity itself as well as in the navigation tree on the <code>Website</code> entity. </p>
  
  <p>I think I understand how entity groups work and the basic implications of using them, but I have trouble deciding on the "best" way to structure my data in the absence of strong reasons for either approach. I could:</p>
  
  <ol>
  <li><p>Go entirely without ancestors on my entities. As far as I understand I can still use cross-group transactions as long as I get the entities by key and don't need more than 5 within the transaction. The downside is that I'd depend on the XG transactions and there might come a point where I can't ninja my way around using ancestor queries anymore (and then it might be too late).</p></li>
  <li><p>Make the user object the parent of all his Website's, Page's and other data. This would give the user a strongly consistent view of all of his data, allow me to use transactions whenever I add a feature that would need them, but limits the sustained writes to 1-5/sec. But, as a user will only ever be updating his own data, this might actually work and behave just the same for 1000 users as it will for 1.</p></li>
  <li><p>Try to use even smaller entity groups (like seperating the navigation from the <code>Website</code> and making that the parent of the Website's Pages). But I'm not quite sure if there's much benefit to this, because most of the editing happens on Pages anyway.</p></li>
  </ol>
  
  <p>So I guess the real question is: how do you decide when to use ancestor relationships on App Engine when there's no obvious reason for or against them? Would you go for the convenience of strongly consistent queries and being able to use transactions freely while adding features later, or would you avoid them at all costs until there's a very obvious reason for them, even if might limit my ability to do transactions later?</p>
  
  <p>I read the related documentation, read the chapter on transactions in "Programming App Engine", looked at quite a few of the Google I/O videos, but I still find it hard to make that decision.</p>