Google AppEngine

Google App Engine applications written in Java can write information to the log files using java.util.logging.Logger. Log data for an application can be viewed and analyzed using the Administration Console, or downloaded using appcfg.sh request_logs. More info in the Logging documentation.

I propose two possiblities: Duplicate Line_Item. Line_Item appointment_key name price finished ... A Line_Item should have a finished state, when the item was finished or not by the employee. If an employee hadn't finished all line items, mark them as unfinished, create a new appointment and copy all items that were unfinished. You can index on the appointment_key field on all Line_Items, which is a Good Thing. However, the duplicated data may be a problem. Dynamic fields for Line_Item: Line_Item duplicate_key appointment_key name price finished ... Create a new field, duplicate_key, for Line_Item which points to another Line_Item or to null (reserve this key!). Null means that the Line_Item is original, any other value means that this Line_Item is a duplicate of the Line_Item the field points to. All fields of Line_Item marked as a duplicate inherit the fields of the original Line_Item, except the appointment_key: so it will take less storage. Also this solution should have appointment_key indexed, to speed up lookup times. This requires one additional query per duplicated Line_Item, which may be a problem. Now, it's a clear choice: either better speed or better storage. I would go for the first, as it reduces complexity of your model, and storage is never a problem with modern systems. Less complexity generally means less bugs and less development/testing costs, which justifies the cost of the storage requirement.

That's a restriction of App Engine's mail API: The sender address can be either the email address of a registered administrator for the application, or the email address of the current signed-in user (the user making the request that is sending the message). If you've got Google Apps running on that domain, you should have (or be able to create) an @thatdomain.com email addresses that you can register as an administrator of the App Engine app in question, which will then let you send email "from" that address.

I have an Entity with an id type of Long, and the id gets filled in after I call makePersistent(). Here is what the code looks like:     GameEntity game = new GameEntity();    log.warning("before makePersistent id is " + game.getId());    pm.makePersistent(game);    log.warning("after makePersistent id is " + game.getId()); Here is a snippet of the GameEntity class: @PersistenceCapable(identityType = IdentityType.APPLICATION)public class GameEntity {    @PrimaryKey    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)    private Long id; And the output shows what you'd expect: WARNING 6428 - before makePersistent id is nullWARNING 6444 - after makePersistent id is 6 UPDATE: It occurred to me belatedly that you might want an actual Key object. You can create that yourself if you have the id: public Key getKey() {    return KeyFactory.createKey(GameEntity.class.getSimpleName(), id);}

I made some code public that does what you describe: it is a simple   cache interface that has implementations for in-memory, memcache and   the datastore.  You get about 100MB of heap space to use which can   significantly speed up your caching. There is also a CompositeCache class that allows you to layer the   caches so that it first checks in-memory, then memcache , then the   datastore.  Puts go to all levels and cache hits refresh the higher   levels.  e.g. if an item is not in-memory and has been flushed from   memcache but is still present in the datastore then the other two will   be updated.

Well, in AppEngine your primary key is the key for the object(Entity) and it can either be a generated ID or a unique string your application provides.  "Google App Engine" by Dan Sanderson has a lot of examples on this.  If you don't use a key_name property, then when you save with a put(), an ID is generated, but if you pass in key_name='thisIsMyKey' into the constructor, then you manually set the key for the object.  You can use the method, id_or_name() to return either the object's key name or its ID, which ever one it has and has_id_or_name() would return a boolean about it, and if it's not saved and your not using key_name, then the ID would not exists yet.  Also you can get the Entity(Object) from the datastore by using the get(k) method where k is a key object and the key object has two parts: kind and ID or key_name.  Additionally you can fetch an object from the datastore with get_by_id() and get_by_key_name()

Right now, when the user removes the GWT/App Engine nature from the project, if they have a SDK container on their build path, it is collapsed into its individual jars, and they are added to the classpath. In some cases, users do not expect this behavior (for example, if they mistakingly added the wrong nature).

signed requests will still be redirected. Auth-constraint only applies to Users logged in via the web or OpenID. This is a good feature request, however, and I will bring it up.

That was referring to the bulkloader, which lets you do those things. App Engine's datastore isn't a relational database. We can't do a dump of all your data without iterating through all of your indexes, then retrieving your Entities.

An end cursor allows you to specify when you want a query to stop. A cursor represents a query start position - an end cursor is another position. This lets you take, say, 10k entities, break them up into 100 "chunks", then do task queue or other background operations on them. Unlike using an offset (cursor +100), this method solves the case of new Entities being inserted, since you're not working with a cursor +100 Entities. You're working with all the Entities between startCursor and endCursor.