The war/ directory uses the WAR standard layout for bundling web applications. (WAR archive files are not yet supported by the SDK.) The Eclipse plugin uses this directory for running the development server, and for deploying the app to App Engine. When Eclipse builds your project, it creates a directory named classes/ in war/WEB-INF/, and puts compiled class files here. Eclipse also copies non-source files found in src/ to war/WEB-INF/classes/, including META-INF/ and the log4j.properties and logging.properties files. The final contents of the war/ directory make up your application for testing and deployment. For details about the new project that the plugin creates, see the Getting Started Guide.

I believe that Twig is the only library that can store objects with entire collections embedded as components. So the Columns could actually be stored in the same entity as the Table. This means that querying or reading Tables is _much_ faster. If the tables are read more than written this would be ideal. Docs are a bit light but basically you just define an embedded collection like this: class Table { @Key String name; @Component Collection<Column> columns; } and thats it! The columns are then stored as a multi-valued property so you can even query properties them like "show all tables with a column named 'age'".

public void setProperty(java.lang.String propertyName, java.lang.Object value) Sets the property named, propertyName, to value. As the value is stored in the datastore, it is converted to the datastore's native type. This may include widening, such as converting a Short to a Long. All Collections are prone to losing their sort order and their original types as they are stored in the datastore. For example, a TreeSet may be returned as a List from getProperty(java.lang.String), with an arbitrary re-ordering of elements. Overrides any existing value for this property, whether indexed or unindexed. Note that Blob and Text property values are never indexed by the built-in single property indexes. To store other types without being indexed, use #setUnindexedProperty. Parameters:value - may be one of the supported datatypes, a heterogenous Collection of one of the supported datatypes, or an UnindexedValue wrapping one of the supported datatypes. Throws: java.lang.IllegalArgumentException - If the value is not of a type that the data store supports.

'm guessing your tests were run locally because the counter in the local datastore does indeed have datastore scope.  The scope of the counter in the prod datastore, however, is parent key + kind.  This is described here: http://code.google.com/appengine/docs/java/datastore/creatinggettinga... If it's important to you that the scope of the generated ids match between dev and and prod please file an issue.

                StringBuffer sb = new StringBuffer();                 KeyRange range = ds.allocateIds("a", 2);                 for (Key key : range) {                         sb.append("\n a " + key.toString());                 }                 range = ds.allocateIds("b", 2);                 for (Key key : range) {                         sb.append("\n b " + key.toString());                 }                 Key parentKey = KeyFactory.createKey("c", 1);                 sb.append("\n c " + parentKey.toString());                 range = ds.allocateIds(parentKey, "d", 2);                 for (Key key : range) {                         sb.append("\n d " + key.toString());                 }                 System.out.println(sb.toString());

The URL I posted earlier in the thread explains it, but here's a little bit more detail: A parent entity plus a kind defines an id-space, so entities with the same parent and the same kind are guaranteed to have unique ids.  For example, if you have an Entity with Parent:A Kind: Person Id: 10 you are guaranteed that no other entity with Parent A and Kind Person will be assigned an Id of 10.  However, an entity with a different Parent and Kind Person or an entity with Parent A and a different Kind _can_ be assigned an Id of 10.  The datastore pre-allocates batches of ids across multiple servers under-the-hood, so you can't make any assumptions about the Id that will get assigned in terms of contiguousness.  The only safe assumption is that the id will be unique for that Parent/Kind combination.

Because A is the entity group parent of B, the key of an instance of B must contain information about its entity group parent instance of A. Instead of using b.key.getId() in   // We cannot retrieve this object. Why?   B newB = pm.getObjectById(B.class,b.key.getId()); you might care to use the KeyFactory.Builder class as detailed in "http://code.google.com/intl/en/appengine/docs/java/datastore/ creatinggettinganddeletingdata.html#Creating_and_Using_Keys" in order to build a key instance which contains information about both your B instance and its parental A instance.