regressiontests.sendfile uses this now, and passes. The fallback was tested
using guppy and apache2 with mod_wsgi for heap issues, and it appears to be
fine. We can go back and look at this again if it becomes an issue.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11212 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Improve charset coverage. Change HttpResponse.status_code to property, which checks for a 406 situation. This also required changes to all HttpResponse subclasses, so that their default status_code is set by _status_code, now.
Passes regression test suite, except ones related to sendfile.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11199 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This does not pass the included regression tests. However, since this feature
will be entirely based on these changes, which have already gone through a
great number of iterations, I thought it would be sensible to start here.
All of the work here is ymasuda, mizatservercave, and mrts (apologies if I
missed anyone). I hope to take their work
down the final stretch.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11131 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The specific cases modified test if the test client will encode the data it posts such that when writers of test views try to use the request, the data will be in the encoding they expect from the tests cases they have written. We do not expect HttpRequest to decode the incoming content yet, so the test views have to be created beforehand so that they decode using the proper codec (which they can determine from the content-type header).
Therefore, once the data is in the view and decoded, we then encode it into settings.DEFAULT_CHARSET, so we can expect normal behavior from HttpResponse, which is for the data to be encoded in settings.DEFAULT_CHARSET. That is what the test cases now assert.
HttpResponse charset handling now passes the entire test suite.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11110 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Changeset 11030 did not actually pass the regression test suite. This passes all except two tests, from test_client_regress. They expect old behavior (which is that their responses will be encoded in settings.DEFAULT_CHARSET). I am not yet sure if that is the correct expectation for the test to have, so I will do investigations into that.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11040 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This code determines the charset from a content-type or from the Accept-Charset request header.
The code is fairly well documented, but that will be improved once the code is in closer to a
final form. The codec that corresponds to the charset is also returned, but it is not currently
used by HttpResponse.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11014 bcc190cf-cafb-0310-a4f2-bffc1f526a37
NOTE: This change is backwards incompatible for some users.
If you are using a 32-bit platform, you will observe no differences as a
result of this change. However, users on 64-bit platforms may experience
some problems using the `reset` management command.
Prior to this change, 64-bit platforms would generate a 64-bit, 16 character
digest in the constraint name; for example:
ALTER TABLE `myapp_sometable` ADD CONSTRAINT `object_id_refs_id_5e8f10c132091d1e` FOREIGN KEY ...
Following this change, all platforms, regardless of word size, will
generate a 32-bit, 8 character digest in the constraint name; for example:
ALTER TABLE `myapp_sometable` ADD CONSTRAINT `object_id_refs_id_32091d1e` FOREIGN KEY ...
As a result of this change, you will not be able to use the `reset`
management command on any table created with 64-bit constraints. This
is because the the new generated name will not match the historically
generated name; as a result, the SQL constructed by the `reset` command
will be invalid.
If you need to reset an application that was created with 64-bit
constraints, you will need to manually drop the old constraint prior
to invoking `reset`.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@11003 bcc190cf-cafb-0310-a4f2-bffc1f526a37
* Moved dimension field update logic out of `ImageFileDescriptor.__set__` and into its own method on `ImageField`.
* New `ImageField.update_dimension_fields` method is attached to model instance's `post_init` signal so that:
* Dimension fields are set when defined before the ImageField.
* Dimension fields are set when the field is assigned in the model constructor (fixes#11196), but only if the dimension fields don't already have values, so we avoid updating the dimensions every time an object is loaded from the database (fixes#11084).
* Clear dimension fields when the ImageField is set to None, which also causes dimension fields to be cleared when `ImageFieldFile.delete()` is used.
* Added many more tests for ImageField that test edge cases we weren't testing before, and moved the ImageField tests out of `file_storage` and into their own module within `model_fields`.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/http-wsgi-improvements@10987 bcc190cf-cafb-0310-a4f2-bffc1f526a37
