That's a good start. However, apart from the startswith/ancestor hack there's another issue: GAEKeyField shouldn't require changes to value_to_db_auto(). Otherwise you'd be allowed to pass a Key object to AutoField. Maybe GAEKeyField should just derive from Field instead of AutoField.
There's also a bigger problem: What if you want to set the parent, but you don't want to specify an id/key_name? (i.e., they should be set automatically by the DB) That's not possible with this solution. Maybe we need a custom Key class or a custom Parent() wrapper or something like that.
This causes a problem because pk is now set, even though it is not complete. So after you save child, the datastore generated key will not be set. Django only sets a new pk when the current one is None.
Not sure what the best way to fix is. A couple of ideas:
1. GAEKeyField.to_python() should return None when the key is not complete to trick django. This seems hackish and will probably cause trouble.
2. Modify django itself to be a bit smarter about setting new primary keys. It seems wrong to do this, and makes it less likely that the changes will be accepted upstream.
3. Do something with signals. I don't know much about signals so this might not work.
4. Instead of GAEKeyField controlling a single attribute, have it control both 'pk' and a new one 'parent_pk'. Django core will only know about PK, but the appengine backend would know about the other attribute, so when inserting, the backend will do the right thing. For example:
key = GAEKeyField(parent_key_attribute="parent_key")
model = Model(parent_key=GAEKey(parent_model))
model.key == None
model.parent_key == GAEKey(...)