…ine into ancestor

… keys

…nonrel/djangoappengine into develop

Conflicts:
	db/compiler.py

It's possible to use a django DateField or TimeField but have your own encoding in the datastore.  In this case, we may not get a datetime value, so check type first.

…eField or TimeField, but may not necessarily be stored as a datetime.

Patch the stub initialization to use the default dev_appserver login url for the user service.  Otherwise it defaults to the live production user service, which we generally don't want while testing.

1. The task queue stub spawns a new thread that causes badness.  Disable task queue while testing to avoid the new thread.
2. If the launched browser is accessing the site and hitting the db, it may conflict with the main thread when it flushes the DB between tests.  The real fix is to ensure the test doesn't complete on the main thread until the browser is done (this includes JS running in browser which may hit the server).  I've put in a hackaround to keep retrying the db flush if it fails.  This is not safe though.

…djangoappengine into django-1.4

Conflicts:
	db/compiler.py

The main benefit of both is to be able to pass in a Django model instead of a db.Model to get Keys or entities.

Note that DjangoEntityInputReader returns a raw entity instead of a Django object instance.
This is particularly useful for working with old entities in the datastore that may not match the latest Django model.  Django's model classes could raise exceptions if properties were missing, but this class will allow fetching those entities.  The developer can then add the missing properties, or whatever.

Fix socket retry code to find unused socket for next test.

This is really limited, a lot of things don't work (like tests and dumpdata)

Figured out how to get manage.py test, shell and dumpdata working.

…ngo-1.4

- Includes LiveServerTestCase which works with Selenium
- Includes merging in AncestorKey implementation
- Includes various other fixes for field types derived from DateTime fields causing breaks.
- Includes fix for User API login not working.
- Include switch to WSGI for python 2.7

Try original dev_appserver code, and fail to devappserver2 version.

….7.5 running dev_appserver, or devappserver2 0.8.

Currently we detect between dev_appserver and devappserver2 based on availability of certain modules.
In SDK 1.7.5, both dev_appserver and devappserver2 are available, and we default to dev_appserver for backwards compatibility.  Does not have a current way to force devappserver2 in this case.

This makes the FileField's ClearableFileInput widget show up properly when there's an existing file in the model.

…b content-type, blob-key, and name.

Force use of devappserver2 by putting a file in the root of your project called force_devappserver.py
The file should contain a single variable:

devappsever_ver = 1 or 2

manage.py runserver, test and remote shell commands work on both devappserver1/2
manage.py shell works on devappserver1 but not devappserver2.
Other commands have not been tested.

Can currently only run one test at a time, since server sometimes fails to shut down.

…commands like manage.py shell/dumpdat work.

We need to patch runserver a bit so that it resets the stubs, otherwise we get an exception in devappserver2.

…pserver2.

Make python manage.py deploy work.  Removed the use of the appcfg -R flag, it shouldn't be necessary.

…e displayed without the blobkey (ie in form FileField)

…ine into appengine-1.4

Conflicts:
	djangoappengine/db/creation.py
	djangoappengine/db/stubs.py
	djangoappengine/db/utils.py
	djangoappengine/tests/__init__.py

This wasn't necessary on the original dev_appserver, but necessary on devappserver2 since it defaults to eventually consistent.
We can remove the same call from testserver in this case.

…r. Oops.

…odels.

…mapreduce library.

…re APIs.

TODO: add PIL to Travis config