Re: file upload fails with slow network bandwith in django

[James Schneider]

On Mon, Feb 15, 2016 at 10:41 PM, Pablo Conesa 
wrote:

> Thanks James. answers in line:
>
> El lunes, 15 de febrero de 2016, 23:04:48 (UTC+1), James Schneider
> escribió:
>>
>>
>>
>> On Mon, Feb 15, 2016 at 10:20 AM, Pablo Conesa 
>> wrote:
>>
>>> Hi, I posted this in stackoverflow. Now I'm trying here:
>>> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django
>>>
>>> I've got a code working fine that uploads a file to a DJANGO server.
>>>
>>> It works fine on a fine connection.
>>>
>>> Now if, using fiddler to simulate a slow connectionpage freezes
>>> (Chrome pop up offering to kill the page).
>>>
>>> I've tested in different ways and the only factor that causes the error
>>> is a slow upload speed. e.g. If I choose a wi-fi network it fails but over
>>> the ethernet it works.
>>>
>>> File is 100MB!.
>>>
>>> python: 2.7.6
>>>
>>> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)
>>>
>>> Fiddler show -1 in the response, and says: "No response body".
>>>
>>> Any ideas?
>>>
>>>
>>
>> How long does the file upload work before receiving the error?
>>
>
> There is no response from the server (fiddler returns -1, whatever this
> means)
>

Well, no response from the server doesn't necessarily mean that there were
no logs. Can you check the error and access logs of the server?

Does Fiddler return an immediate response of -1, or does it seem like there
is a timeout period?

After a quick glance at Fiddler itself, are you using any customizations on
the rules


>> My guess is that Fiddler is attempting to use an HTTP chunked transfer to
>> send the file 'slowly' (by rate-limiting the chunks it sends rather than
>> traffic shaping the data stream itself), which is how modern JS libraries
>> normally handle large file uploads. However, this takes advantage of
>> features built into the HTTP 1.1 standard, and I'm not entirely sure
>> whether or not the Django dev server fully implements HTTP 1.1. That would
>> explain why you are getting a response body error (since the Django dev
>> server probably doesn't understand chunked requests and doesn't know to
>> expect more data). See https://code.djangoproject.com/ticket/25619
>> 
>> That's purely a guess though, as I'm not familiar with how Fiddler works,
>> and Django's internal support for HTTP 1.1 is somewhat ambiguous.
>>
>
> Don't know either details about FIddler..but what you are saying sounds
> reasonable and in the right direction...
>
>>
>> This type of testing should be done against the production server (which
>> likely fully implements HTTP 1.1), not the Django dev server, since
>> performance of the dev server cannot be correlated with a production server
>> that implements threading and/or multiple worker processes.
>>
>
> I've done this. Actually the bug was reported in production (apache
> forwarding to guinicorn)
>

Hmm, Apache should handle that fine. It's had 1.1 support forever, and I
don't believe it requires any special configuration. Might be related to
gunicorn, though, if it is responsible for handling the chunked response.
Found this to be similar to your issue:
https://github.com/benoitc/gunicorn/issues/1125, although sadly no
resolution. Might point you in the right direction, though.



>
>
>>
>> On a side note, though. If you plan to have users regularly upload large
>> files (>2MB), you should seriously look in to implementing chunked uploads
>> via a JS library. With a standard upload via a regular form, the worker
>> process in your server handling the upload are dedicated to that upload
>> until it finishes. Usually this is fine for small uploads, but for larger
>> uploads that can take minutes or hours, it becomes a large problem even on
>> a site with a small user base. If 5 users are uploading a large file, and
>> you only have 5 worker processes running, then literally nobody can access
>> your site until at least one of those uploads finishes. With chunked
>> transfers, the file is broken up into pieces and sent as many small
>> requests rather than a single large one. This allows a server worker
>> process to process the small upload, then step away to serve other users,
>> and then process the next small upload. The net result on a busy server is
>> usually a slower response, but at least there is a response.
>>
>
> Nice advice...I'll look into this. Do you know any nice example for that
> JS library chunk upload.
>
>>
>>

Probably best to stick with your existing JS framework of choice if you are
using one. All of the major ones have some version of a chunked uploader
(JQuery and Angular), and I come across resumable.js fairly frequently.
I've never personally had a need for one, so I can't really comment on them
in any sort of detail or make a recommendation.

-James

-- 
You received this message because you are subscribed to the

Re: [Recipe] Rename a model and its table

[Mike Dewhirst]

The trouble with fixtures has been fixed. It was caused by the existence 
of group_permissions including Oldname. As soon as I removed them 
everything is sweetness and light :)


I'm still interested in comments on sequences and indexes using Oldname 
embedded in their names even though it doesn't seem to affect anything.


Cheers

Mike

On 16/02/2016 1:27 PM, Mike Dewhirst wrote:
Hold on. I'm now having trouble with fixtures so please don't follow 
the recipe until I work it out. So far it seems only the table name 
has changed to Newname and it still uses all the Oldname sequences and 
indexes - which are owned by Newname.


Applications using Newname all work Ok.

Back to the drawing board. I'm now thinking creating a new table might 
be better and copying data the correct way to proceed.


Anyone else have any comments?

Thanks

Mike

On 15/02/2016 7:46 PM, Mike Dewhirst wrote:
I was postponing this but shouldn't have worried. Despite the 
complexities evident in various web recipes after googling, this is 
my simple recipe:


Python 2.7 and 3.4, Django 1.8 and Postgres 9.3 on Windows 8.1 and
Python 2.7, Django 1.8 and Postgres 9.1 on Ubuntu 12.04

1. Run all unit tests

2. Change model name to class Newname(...)

3. Resolve all the obvious issues by running the dev server, identify 
where things go wrong and repair them until the project software is 
mostly running with the Newname model. You may not get it to run but 
the dev server should not identify too many issues. Note, you may get 
the odd ProgrammingError - relation "Oldname" does not exist. Don't 
worry too much because you haven't renamed the table yet.


4. Create an empty migration using the --empty flag

5. Edit the empty operations list like this ...

operations = [
    migrations.RenameModel('Oldname', 'Newname')
    migrations.AlterModelTable('Newname', 'appname_newname'),
]

6. migrate

Note, you will probably need to or perhaps should delete stale 
content types at the end of the migration.


7. Run all unit tests

Thank you Sir Andrew and Django

Hope this helps someone

Mike







--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/56C2C943.4000402%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: file upload fails with slow network bandwith in django

[Pablo Conesa]

Thanks James. answers in line:

El lunes, 15 de febrero de 2016, 23:04:48 (UTC+1), James Schneider escribió:
>
>
>
> On Mon, Feb 15, 2016 at 10:20 AM, Pablo Conesa  > wrote:
>
>> Hi, I posted this in stackoverflow. Now I'm trying here: 
>> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django
>>
>> I've got a code working fine that uploads a file to a DJANGO server.
>>
>> It works fine on a fine connection.
>>
>> Now if, using fiddler to simulate a slow connectionpage freezes 
>> (Chrome pop up offering to kill the page).
>>
>> I've tested in different ways and the only factor that causes the error 
>> is a slow upload speed. e.g. If I choose a wi-fi network it fails but over 
>> the ethernet it works.
>>
>> File is 100MB!.
>>
>> python: 2.7.6 
>>
>> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)
>>
>> Fiddler show -1 in the response, and says: "No response body".
>>
>> Any ideas?
>>
>>
>
> How long does the file upload work before receiving the error? 
>

There is no response from the server (fiddler returns -1, whatever this 
means) 

>
> My guess is that Fiddler is attempting to use an HTTP chunked transfer to 
> send the file 'slowly' (by rate-limiting the chunks it sends rather than 
> traffic shaping the data stream itself), which is how modern JS libraries 
> normally handle large file uploads. However, this takes advantage of 
> features built into the HTTP 1.1 standard, and I'm not entirely sure 
> whether or not the Django dev server fully implements HTTP 1.1. That would 
> explain why you are getting a response body error (since the Django dev 
> server probably doesn't understand chunked requests and doesn't know to 
> expect more data). See https://code.djangoproject.com/ticket/25619 
> 
>  
> That's purely a guess though, as I'm not familiar with how Fiddler works, 
> and Django's internal support for HTTP 1.1 is somewhat ambiguous. 
>

Don't know either details about FIddler..but what you are saying sounds 
reasonable and in the right direction...

>
> This type of testing should be done against the production server (which 
> likely fully implements HTTP 1.1), not the Django dev server, since 
> performance of the dev server cannot be correlated with a production server 
> that implements threading and/or multiple worker processes.
>

I've done this. Actually the bug was reported in production (apache 
forwarding to guinicorn)
 

>
> On a side note, though. If you plan to have users regularly upload large 
> files (>2MB), you should seriously look in to implementing chunked uploads 
> via a JS library. With a standard upload via a regular form, the worker 
> process in your server handling the upload are dedicated to that upload 
> until it finishes. Usually this is fine for small uploads, but for larger 
> uploads that can take minutes or hours, it becomes a large problem even on 
> a site with a small user base. If 5 users are uploading a large file, and 
> you only have 5 worker processes running, then literally nobody can access 
> your site until at least one of those uploads finishes. With chunked 
> transfers, the file is broken up into pieces and sent as many small 
> requests rather than a single large one. This allows a server worker 
> process to process the small upload, then step away to serve other users, 
> and then process the next small upload. The net result on a busy server is 
> usually a slower response, but at least there is a response.
>

Nice advice...I'll look into this. Do you know any nice example for that JS 
library chunk upload.

>
> -James
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3d400904-8fe8-460c-b9cd-e8ba6521a96a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: file upload fails with slow network bandwith in django

[Pablo Conesa]

Thanks Ezequiel, answer below.

El lunes, 15 de febrero de 2016, 21:22:23 (UTC+1), Ezequiel Bertti escribió:
>
> You are using de runserver to develop and getting this error or something 
> like gunicorn and nginx?
>

In production  we are using gunicorn, locally I don't use guinicorn, and in 
both cases it happens the same.

Unfortunately there is no message, no time out, nothing from the server.

>
> Because the nginx have some time to proccess each request.
>
> http://stackoverflow.com/questions/6816215/gunicorn-nginx-timeout-problem 
> 
>
> On Mon, Feb 15, 2016 at 4:20 PM, Pablo Conesa  > wrote:
>
>> Hi, I posted this in stackoverflow. Now I'm trying here: 
>> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django
>>
>> I've got a code working fine that uploads a file to a DJANGO server.
>>
>> It works fine on a fine connection.
>>
>> Now if, using fiddler to simulate a slow connectionpage freezes 
>> (Chrome pop up offering to kill the page).
>>
>> I've tested in different ways and the only factor that causes the error 
>> is a slow upload speed. e.g. If I choose a wi-fi network it fails but over 
>> the ethernet it works.
>>
>> File is 100MB!.
>>
>> python: 2.7.6 
>>
>> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)
>>
>> Fiddler show -1 in the response, and says: "No response body".
>>
>> Any ideas?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/3625feed-bc42-4d80-a8cb-d6a8c94a48cf%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Ezequiel Bertti
> E-Mail: ebe...@gmail.com 
> Cel: (21) 99188-4860
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0307bb9e-01dd-4f52-a004-b0f7277b9354%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.9: verbose_name and verbose_name_plural

[Tim Graham]

Interesting I have no idea how that's related but I'm glad it's solved 
for you.

On Monday, February 15, 2016 at 4:17:37 PM UTC-5, Marco Badan wrote:
>
> oh, it was you that fixed the warning in django-cms so... thanks again
>
> Il giorno lunedì 15 febbraio 2016 22:06:05 UTC+1, Marco Badan ha scritto:
>>
>> ok,
>>
>> I was able to isolate the url: it's from django cms 3.2.1.
>> The django cms devs have already fixed the warning 
>> (*django.conf.urls.patterns() 
>> is deprecated and will be removed in Django 1.10*) in develop branch.
>>
>> I get the unwanted behaviour if I put back the warning using 
>> *django.conf.urls.patterns*
>>
>> For reference:
>> the url is here 
>>  and 
>> the related view is WizardCreateView 
>> 
>> .
>>
>> Cheers
>> Marco
>>
>> Il giorno lunedì 15 febbraio 2016 15:31:34 UTC+1, Tim Graham ha scritto:
>>>
>>> Hm, see if you can isolate which URL pattern is causing the issue. Seems 
>>> like there might be a module level translation activation that's triggered 
>>> when the urlpatterns are processed.
>>>
>>> On Sunday, February 14, 2016 at 6:37:58 AM UTC-5, Marco Badan wrote:

 Hi Tim,

 my models (and all my project files) contain only english strings. 
 Italian is only on *.po files.

 I used git bisect and this is the first commit that triggers the 
 migrations:

 https://github.com/django/django/commit/fe3fc5210f0bb334a679ed420152af1c862c0239

 And it's about urls, not migrations.
 I've a few RemovedInDjango110Warnings related to urls due to 3rd 
 parties packages (django.conf.urls.patterns() is deprecated, Support for 
 string view arguments to url() is deprecated)


 Il giorno domenica 14 febbraio 2016 03:59:31 UTC+1, Tim Graham ha 
 scritto:
>
> The only thing that comes to mind is a paragraph in the 1.8 release 
> notes, "When the leave_locale_alone 
> 
>  
> attribute is False, translations are now deactivated instead of 
> forcing the “en-us” locale. In the case your models contained non-English 
> strings and you counted on English translations to be activated in 
> management commands, this will not happen any longer. It might be that 
> new 
> database migrations are generated (once) after migrating to 1.8." but you 
> said you upgraded from 1.8 to 1.9, so I guess it isn't relevant.
>
> If you could bisect Django's commit history to find where the behavior 
> changed, that might yield some insight.
>
> On Saturday, February 13, 2016 at 8:35:52 AM UTC-5, Marco Badan wrote:
>>
>> Hello, 
>> I've upgraded a project to Django 1.9.
>>
>> I've:
>> LANGUAGE_CODE = 'it'
>> LANGUAGES = (('it', 'Italian'),)
>>
>> With Django 1.8 after running makemigrations I got the no changes 
>> detected message.
>>
>> On 1.9 makemigrations creates migrations for all of my apps and all 
>> third party apps.
>>
>> I had a look at the new migration files and I've a lot of 
>> AlterModelOptions and AlterField.
>> The relevant changes are on verbose_name and verbose_name_plural:
>> With 1.8 I had untranslated strings (English), with 1.9 I've the 
>> translated strings in Italian.
>>
>> (...)
>> 
>> operations = [
>> migrations.AlterModelOptions(
>> name='category',
>> options={'verbose_name': 'categoria', 
>> 'verbose_name_plural': 'categorie'},
>> ),
>> migrations.AlterField(
>> model_name='category',
>> name='description',
>> field=models.TextField(verbose_name='descrizione'),
>> ),
>>
>> (...)
>> 
>> ]
>>
>> How can I avoid this behaviour?
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/65665522-101a-40dd-b27b-5dc14ba9c757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: file upload fails with slow network bandwith in django

[James Schneider]

On Mon, Feb 15, 2016 at 10:20 AM, Pablo Conesa 
wrote:

> Hi, I posted this in stackoverflow. Now I'm trying here:
> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django
>
> I've got a code working fine that uploads a file to a DJANGO server.
>
> It works fine on a fine connection.
>
> Now if, using fiddler to simulate a slow connectionpage freezes
> (Chrome pop up offering to kill the page).
>
> I've tested in different ways and the only factor that causes the error is
> a slow upload speed. e.g. If I choose a wi-fi network it fails but over the
> ethernet it works.
>
> File is 100MB!.
>
> python: 2.7.6
>
> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)
>
> Fiddler show -1 in the response, and says: "No response body".
>
> Any ideas?
>
>

How long does the file upload work before receiving the error?

My guess is that Fiddler is attempting to use an HTTP chunked transfer to
send the file 'slowly' (by rate-limiting the chunks it sends rather than
traffic shaping the data stream itself), which is how modern JS libraries
normally handle large file uploads. However, this takes advantage of
features built into the HTTP 1.1 standard, and I'm not entirely sure
whether or not the Django dev server fully implements HTTP 1.1. That would
explain why you are getting a response body error (since the Django dev
server probably doesn't understand chunked requests and doesn't know to
expect more data). See https://code.djangoproject.com/ticket/25619 That's
purely a guess though, as I'm not familiar with how Fiddler works, and
Django's internal support for HTTP 1.1 is somewhat ambiguous.

This type of testing should be done against the production server (which
likely fully implements HTTP 1.1), not the Django dev server, since
performance of the dev server cannot be correlated with a production server
that implements threading and/or multiple worker processes.

On a side note, though. If you plan to have users regularly upload large
files (>2MB), you should seriously look in to implementing chunked uploads
via a JS library. With a standard upload via a regular form, the worker
process in your server handling the upload are dedicated to that upload
until it finishes. Usually this is fine for small uploads, but for larger
uploads that can take minutes or hours, it becomes a large problem even on
a site with a small user base. If 5 users are uploading a large file, and
you only have 5 worker processes running, then literally nobody can access
your site until at least one of those uploads finishes. With chunked
transfers, the file is broken up into pieces and sent as many small
requests rather than a single large one. This allows a server worker
process to process the small upload, then step away to serve other users,
and then process the next small upload. The net result on a busy server is
usually a slower response, but at least there is a response.

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVkP4PWcnteD36qV8R5KB2t%2BmEgO00ONbiEXPNT%2B_7yKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.9: verbose_name and verbose_name_plural

[Marco Badan]

oh, it was you that fixed the warning in django-cms so... thanks again

Il giorno lunedì 15 febbraio 2016 22:06:05 UTC+1, Marco Badan ha scritto:
>
> ok,
>
> I was able to isolate the url: it's from django cms 3.2.1.
> The django cms devs have already fixed the warning 
> (*django.conf.urls.patterns() 
> is deprecated and will be removed in Django 1.10*) in develop branch.
>
> I get the unwanted behaviour if I put back the warning using 
> *django.conf.urls.patterns*
>
> For reference:
> the url is here 
>  and 
> the related view is WizardCreateView 
> 
> .
>
> Cheers
> Marco
>
> Il giorno lunedì 15 febbraio 2016 15:31:34 UTC+1, Tim Graham ha scritto:
>>
>> Hm, see if you can isolate which URL pattern is causing the issue. Seems 
>> like there might be a module level translation activation that's triggered 
>> when the urlpatterns are processed.
>>
>> On Sunday, February 14, 2016 at 6:37:58 AM UTC-5, Marco Badan wrote:
>>>
>>> Hi Tim,
>>>
>>> my models (and all my project files) contain only english strings. 
>>> Italian is only on *.po files.
>>>
>>> I used git bisect and this is the first commit that triggers the 
>>> migrations:
>>>
>>> https://github.com/django/django/commit/fe3fc5210f0bb334a679ed420152af1c862c0239
>>>
>>> And it's about urls, not migrations.
>>> I've a few RemovedInDjango110Warnings related to urls due to 3rd parties 
>>> packages (django.conf.urls.patterns() is deprecated, Support for string 
>>> view arguments to url() is deprecated)
>>>
>>>
>>> Il giorno domenica 14 febbraio 2016 03:59:31 UTC+1, Tim Graham ha 
>>> scritto:

 The only thing that comes to mind is a paragraph in the 1.8 release 
 notes, "When the leave_locale_alone 
 
  
 attribute is False, translations are now deactivated instead of 
 forcing the “en-us” locale. In the case your models contained non-English 
 strings and you counted on English translations to be activated in 
 management commands, this will not happen any longer. It might be that new 
 database migrations are generated (once) after migrating to 1.8." but you 
 said you upgraded from 1.8 to 1.9, so I guess it isn't relevant.

 If you could bisect Django's commit history to find where the behavior 
 changed, that might yield some insight.

 On Saturday, February 13, 2016 at 8:35:52 AM UTC-5, Marco Badan wrote:
>
> Hello, 
> I've upgraded a project to Django 1.9.
>
> I've:
> LANGUAGE_CODE = 'it'
> LANGUAGES = (('it', 'Italian'),)
>
> With Django 1.8 after running makemigrations I got the no changes 
> detected message.
>
> On 1.9 makemigrations creates migrations for all of my apps and all 
> third party apps.
>
> I had a look at the new migration files and I've a lot of 
> AlterModelOptions and AlterField.
> The relevant changes are on verbose_name and verbose_name_plural:
> With 1.8 I had untranslated strings (English), with 1.9 I've the 
> translated strings in Italian.
>
> (...)
> 
> operations = [
> migrations.AlterModelOptions(
> name='category',
> options={'verbose_name': 'categoria', 
> 'verbose_name_plural': 'categorie'},
> ),
> migrations.AlterField(
> model_name='category',
> name='description',
> field=models.TextField(verbose_name='descrizione'),
> ),
>
> (...)
> 
> ]
>
> How can I avoid this behaviour?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/58afb2f5-2d9f-4760-8d96-721c6f2637f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.9: verbose_name and verbose_name_plural

[Marco Badan]

ok,

I was able to isolate the url: it's from django cms 3.2.1.
The django cms devs have already fixed the warning 
(*django.conf.urls.patterns() 
is deprecated and will be removed in Django 1.10*) in develop branch.

I get the unwanted behaviour if I put back the warning using 
*django.conf.urls.patterns*

For reference:
the url is here 
 and 
the related view is WizardCreateView 

.

Cheers
Marco

Il giorno lunedì 15 febbraio 2016 15:31:34 UTC+1, Tim Graham ha scritto:
>
> Hm, see if you can isolate which URL pattern is causing the issue. Seems 
> like there might be a module level translation activation that's triggered 
> when the urlpatterns are processed.
>
> On Sunday, February 14, 2016 at 6:37:58 AM UTC-5, Marco Badan wrote:
>>
>> Hi Tim,
>>
>> my models (and all my project files) contain only english strings. 
>> Italian is only on *.po files.
>>
>> I used git bisect and this is the first commit that triggers the 
>> migrations:
>>
>> https://github.com/django/django/commit/fe3fc5210f0bb334a679ed420152af1c862c0239
>>
>> And it's about urls, not migrations.
>> I've a few RemovedInDjango110Warnings related to urls due to 3rd parties 
>> packages (django.conf.urls.patterns() is deprecated, Support for string 
>> view arguments to url() is deprecated)
>>
>>
>> Il giorno domenica 14 febbraio 2016 03:59:31 UTC+1, Tim Graham ha scritto:
>>>
>>> The only thing that comes to mind is a paragraph in the 1.8 release 
>>> notes, "When the leave_locale_alone 
>>> 
>>>  
>>> attribute is False, translations are now deactivated instead of forcing 
>>> the “en-us” locale. In the case your models contained non-English strings 
>>> and you counted on English translations to be activated in management 
>>> commands, this will not happen any longer. It might be that new database 
>>> migrations are generated (once) after migrating to 1.8." but you said you 
>>> upgraded from 1.8 to 1.9, so I guess it isn't relevant.
>>>
>>> If you could bisect Django's commit history to find where the behavior 
>>> changed, that might yield some insight.
>>>
>>> On Saturday, February 13, 2016 at 8:35:52 AM UTC-5, Marco Badan wrote:

 Hello, 
 I've upgraded a project to Django 1.9.

 I've:
 LANGUAGE_CODE = 'it'
 LANGUAGES = (('it', 'Italian'),)

 With Django 1.8 after running makemigrations I got the no changes 
 detected message.

 On 1.9 makemigrations creates migrations for all of my apps and all 
 third party apps.

 I had a look at the new migration files and I've a lot of 
 AlterModelOptions and AlterField.
 The relevant changes are on verbose_name and verbose_name_plural:
 With 1.8 I had untranslated strings (English), with 1.9 I've the 
 translated strings in Italian.

 (...)
 
 operations = [
 migrations.AlterModelOptions(
 name='category',
 options={'verbose_name': 'categoria', 
 'verbose_name_plural': 'categorie'},
 ),
 migrations.AlterField(
 model_name='category',
 name='description',
 field=models.TextField(verbose_name='descrizione'),
 ),

 (...)
 
 ]

 How can I avoid this behaviour?



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/93eb650f-27f5-42df-963b-4371bf723b7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: file upload fails with slow network bandwith in django

[Ezequiel Bertti]

You are using de runserver to develop and getting this error or something
like gunicorn and nginx?

Because the nginx have some time to proccess each request.

http://stackoverflow.com/questions/6816215/gunicorn-nginx-timeout-problem

On Mon, Feb 15, 2016 at 4:20 PM, Pablo Conesa 
wrote:

> Hi, I posted this in stackoverflow. Now I'm trying here:
> http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django
>
> I've got a code working fine that uploads a file to a DJANGO server.
>
> It works fine on a fine connection.
>
> Now if, using fiddler to simulate a slow connectionpage freezes
> (Chrome pop up offering to kill the page).
>
> I've tested in different ways and the only factor that causes the error is
> a slow upload speed. e.g. If I choose a wi-fi network it fails but over the
> ethernet it works.
>
> File is 100MB!.
>
> python: 2.7.6
>
> DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)
>
> Fiddler show -1 in the response, and says: "No response body".
>
> Any ideas?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/3625feed-bc42-4d80-a8cb-d6a8c94a48cf%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Ezequiel Bertti
E-Mail: eber...@gmail.com
Cel: (21) 99188-4860

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACrQMYpb6pcEmObzZBL%3Dm05sCTtfp2ezcpG51TROdGueFmROeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

file upload fails with slow network bandwith in django

[Pablo Conesa]

Hi, I posted this in stackoverflow. Now I'm trying 
here: 
http://stackoverflow.com/questions/35413649/file-upload-fails-with-slow-network-bandwith-in-django

I've got a code working fine that uploads a file to a DJANGO server.

It works fine on a fine connection.

Now if, using fiddler to simulate a slow connectionpage freezes (Chrome 
pop up offering to kill the page).

I've tested in different ways and the only factor that causes the error is 
a slow upload speed. e.g. If I choose a wi-fi network it fails but over the 
ethernet it works.

File is 100MB!.

python: 2.7.6 

DJANGO: 1.5.5 or 1.9 (I updated to 1.9 and is not working either)

Fiddler show -1 in the response, and says: "No response body".

Any ideas?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3625feed-bc42-4d80-a8cb-d6a8c94a48cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tutorial 5 (Testing) seems to have an error

[Tim Graham]

It looks like you have a Python path problem or that your project isn't 
structured correctly such that the model is being registered twice. Does 
that mean anything to you? I'm not sure if you are also new to Python or 
just to Django.

On Monday, February 15, 2016 at 11:16:51 AM UTC-5, Eric Livingston wrote:
>
> I have been walking through the Tutorial for Django, and upon reaching 
> part 5 and introducing the first test case, I get this output (the 
> directory I put the tutorial in is called 'demo')
>
>  
>
> RuntimeError: Model class demo.polls.models.Question doesn't declare an 
> explicit app_label and isn't in an application in INSTALLED_APPS.
>
>  
>
> I tried adding a Meta section to the Question model, after doing some 
> poking around in the docs.
>
>  
>
> class Question(models.Model):
>
> question_text = models.CharField(max_length=200)
>
> pub_date = models.DateTimeField('date published')
>
>  
>
> class Meta:
>
> app_label='polls'
>
>  
>
> But then I get this:
>
>  
>
> RuntimeError: Conflicting 'question' models in application 'polls':  'polls.models.Question'> and .
>
>  
>
> What modifications would I have to make to the standard Tutorial code so 
> the Models are correctly bound to the polls app? Do I have to add something 
> else to the installed_apps besides 'polls.apps.PollsConfig'? That's the 
> only thing the tutorial says to add.
>
>  
>
> Thanks,
>
> Eric
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7f1db3e4-6f3a-43dc-99e7-59d5d2d1fddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Data base connection problem

[James Schneider]

>
> On Feb 13, 2016 9:42 PM, "ahmed waqas Nasir"  wrote:
>> >
>> > i have made a model  names STUDENT and when i run migrataion no
>> migration applied but when from admin i tried to browse student i got
>> following error
>>
>> Have you run 'manage.py makemigrations' to generate a new migration, and
>> then run 'manage.py migrate'? It sounds like you haven't created a new
>> migration file to apply after making your changes.
>>
>> -James
>>
>
> yes i did run makemigrations  ... but i got following response  no
> changes to apply
>

Have you applied the existing migrations?

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXLyh2mu6yq_wuuMqv5AtoyZ%2B_ihkOSVBeORfWp_SBbMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: mathematical function and django connect

[James Schneider]

On Tue, Feb 9, 2016 at 11:47 AM, Xristos Xristoou  wrote:

> hello,
>
>
> i create some python mathematical function on python idle,
> i want to create website where the user import value numbers on the
> function
> and take the results from that.
>

Usually this is done through a form. You can either have the user provide
the necessary values directly in input fields, or have the user upload a
file containing the information that your view will parse.


> question one,how to connect my mathematical function on the django?
>

Normally you would have the function on your path and import it for use
within your view. Nothing fancy required.


> question two,how to connect input and output from the scipts in the
> website ?
>

Generally your 'script' containing your math functions would not run
separately, rather they would be imported directly and run as part of the
same process that is running Django. You would add the necessary 'from foo
import bar' statements to grab the functions you need, and then simply
execute the functions from the data that you gathered in the form (or
parsed from the uploaded file from the user).

If the mathematical operations will take longer than a few seconds to
execute, you should also consider a batch processor to handle performing
the calculations in the background and having the user return to a status
page where they can check on their jobs. Long-running processes in the web
server can easily choke resources for a variety of reasons, whereas a batch
processor (such as Celery) is purpose-built to handle such operations.


> the second question i ask because input and output from the function is a
> dynamic define from the user
>

Gathering dynamic data is the entire purpose of forms. If all data from the
user was static, we'd never need to gather information from them. Complete
the tutorial project if you haven't done so, and that should become clear.

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVK%2BjHraX44WtCg-XbH%3DvxUhEQCu2UxHLXkcHzZ%2BuMYqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Data base connection problem

[namal . feedback]

On Sunday, February 14, 2016 at 10:48:37 AM UTC+5, James Schneider wrote:
>
>
> On Feb 13, 2016 9:42 PM, "ahmed waqas Nasir"  > wrote:
> >
> > i have made a model  names STUDENT and when i run migrataion no 
> migration applied but when from admin i tried to browse student i got 
> following error
>
> Have you run 'manage.py makemigrations' to generate a new migration, and 
> then run 'manage.py migrate'? It sounds like you haven't created a new 
> migration file to apply after making your changes.
>
> -James
>

yes i did run makemigrations  ... but i got following response  no 
changes to apply 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ec9e7f9d-9dfc-44f4-85fe-452e073e7d85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tutorial 5 (Testing) seems to have an error

[Eric Livingston]

I have been walking through the Tutorial for Django, and upon reaching part 
5 and introducing the first test case, I get this output (the directory I 
put the tutorial in is called 'demo')

 

RuntimeError: Model class demo.polls.models.Question doesn't declare an 
explicit app_label and isn't in an application in INSTALLED_APPS.

 

I tried adding a Meta section to the Question model, after doing some 
poking around in the docs.

 

class Question(models.Model):

question_text = models.CharField(max_length=200)

pub_date = models.DateTimeField('date published')

 

class Meta:

app_label='polls'

 

But then I get this:

 

RuntimeError: Conflicting 'question' models in application 'polls':  and .

 

What modifications would I have to make to the standard Tutorial code so 
the Models are correctly bound to the polls app? Do I have to add something 
else to the installed_apps besides 'polls.apps.PollsConfig'? That's the 
only thing the tutorial says to add.

 

Thanks,

Eric

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bf6740d8-3b1b-44de-a396-ab1b95b183c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: mathematical function and django connect

[Xristos Xristoou]

after read your toturial from the django docs and next page from the django 
docs
i think so my python code is wrong to get in views.py, i think so get in 
form
Τη Τρίτη, 9 Φεβρουαρίου 2016 - 9:47:30 μ.μ. UTC+2, ο χρήστης Xristos 
Xristoou έγραψε:
>
> hello,
>
>
> i create some python mathematical function on python idle,
> i want to create website where the user import value numbers on the 
> function
> and take the results from that.
> question one,how to connect my mathematical function on the django?
> question two,how to connect input and output from the scipts in the 
> website ?
> the second question i ask because input and output from the function is a 
> dynamic define from the user
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f4806da4-886f-4562-8e46-4633693b333e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.9: verbose_name and verbose_name_plural

[Tim Graham]

Hm, see if you can isolate which URL pattern is causing the issue. Seems 
like there might be a module level translation activation that's triggered 
when the urlpatterns are processed.

On Sunday, February 14, 2016 at 6:37:58 AM UTC-5, Marco Badan wrote:
>
> Hi Tim,
>
> my models (and all my project files) contain only english strings. Italian 
> is only on *.po files.
>
> I used git bisect and this is the first commit that triggers the 
> migrations:
>
> https://github.com/django/django/commit/fe3fc5210f0bb334a679ed420152af1c862c0239
>
> And it's about urls, not migrations.
> I've a few RemovedInDjango110Warnings related to urls due to 3rd parties 
> packages (django.conf.urls.patterns() is deprecated, Support for string 
> view arguments to url() is deprecated)
>
>
> Il giorno domenica 14 febbraio 2016 03:59:31 UTC+1, Tim Graham ha scritto:
>>
>> The only thing that comes to mind is a paragraph in the 1.8 release 
>> notes, "When the leave_locale_alone 
>> 
>>  
>> attribute is False, translations are now deactivated instead of forcing 
>> the “en-us” locale. In the case your models contained non-English strings 
>> and you counted on English translations to be activated in management 
>> commands, this will not happen any longer. It might be that new database 
>> migrations are generated (once) after migrating to 1.8." but you said you 
>> upgraded from 1.8 to 1.9, so I guess it isn't relevant.
>>
>> If you could bisect Django's commit history to find where the behavior 
>> changed, that might yield some insight.
>>
>> On Saturday, February 13, 2016 at 8:35:52 AM UTC-5, Marco Badan wrote:
>>>
>>> Hello, 
>>> I've upgraded a project to Django 1.9.
>>>
>>> I've:
>>> LANGUAGE_CODE = 'it'
>>> LANGUAGES = (('it', 'Italian'),)
>>>
>>> With Django 1.8 after running makemigrations I got the no changes 
>>> detected message.
>>>
>>> On 1.9 makemigrations creates migrations for all of my apps and all 
>>> third party apps.
>>>
>>> I had a look at the new migration files and I've a lot of 
>>> AlterModelOptions and AlterField.
>>> The relevant changes are on verbose_name and verbose_name_plural:
>>> With 1.8 I had untranslated strings (English), with 1.9 I've the 
>>> translated strings in Italian.
>>>
>>> (...)
>>> 
>>> operations = [
>>> migrations.AlterModelOptions(
>>> name='category',
>>> options={'verbose_name': 'categoria', 'verbose_name_plural': 
>>> 'categorie'},
>>> ),
>>> migrations.AlterField(
>>> model_name='category',
>>> name='description',
>>> field=models.TextField(verbose_name='descrizione'),
>>> ),
>>>
>>> (...)
>>> 
>>> ]
>>>
>>> How can I avoid this behaviour?
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/59c0a36d-a9c5-49e1-999f-6a1239d71873%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: use django logging from outside

[Det S. Pillner]

On Thursday, February 11, 2016 at 1:32:51 PM UTC+1, Det S. Pillner wrote:
>
>
>
> On Saturday, January 23, 2016 at 11:38:31 AM UTC+1, James Schneider wrote:
>>
>>
>> On Jan 20, 2016 2:35 AM, "Det S. Pillner"  wrote:
>> >
>> > Hi all,
>> >
>> > I work on a django project. I use very heavy logging in this project. 
>> Some parts of code needs to start over a cron job outside of the django 
>> project. In this - I call it modules - I try to use my existing django 
>> logging config. Code execution displays no errors bud there are no logging 
>> entries.
>> >
>> > Can somebody help to fix my problem?
>> >
>>
>> Are you bring in your entire Django environment via a django.setup() 
>> call, or are you simply trying to import the logging configuration that is 
>> being used by your Django project?
>>
>> Without some explanation of what you've tried, I don't think we have 
>> enough information to help.
>>
>> -James
>>
>
> Oh Sorry for the late answer. Holiday.
>
> Here is the content of my bash script to call one of the modules that I 
> use from outside of Django:
>
>
>   
> # django/python settings
>
> PYTHONPATH="${PYTHONPATH}:/srv/wpkg_webtools/"
> export PYTHONPATH
> export DJANGO_SETTINGS_MODULE=wpkg_webtools.settings.privat
>
> # call python part (django module)
> python /srv/wpkg_webtools/wpkg/modules/fill.py $1
>
>
> This script is called from a cron job and find.
>
> In my module I use this:
>
> import os
> import os.path
> import glob
> import sys
> import xml.etree.ElementTree as eTree
> import logging
> import logging.config
> import logging.handlers
> from time import gmtime, strftime
>
> from django.db import connection
>
> from wpkg.models.wpkg import *
>
> logger = logging.getLogger('imp')  # global logger for fill
>
>
> I does not get a error message. That means: Python can find all things. 
> And below: a part from settings.py:
>
> 'imp': {
> 'handlers': ['import'],
> 'level': 'DEBUG',
> },
>
>
> This logger is used by other parts IN django also.
>
> Thanks for your reaction. I will try django.setup() in the head of my 
> module.
>

Tested . Works great.

No I use django.setup() in __main__ section and get logger in function. 
Many thanks. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/108a653a-3465-4daf-8f42-8e1f92c0766d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Recipe] Rename a model and its table

[Mike Dewhirst]

I was postponing this but shouldn't have worried. Despite the 
complexities evident in various web recipes after googling, this is my 
simple recipe:


Python 2.7 and 3.4, Django 1.8 and Postgres 9.3 on Windows 8.1 and
Python 2.7, Django 1.8 and Postgres 9.1 on Ubuntu 12.04

1. Run all unit tests

2. Change model name to class Newname(...)

3. Resolve all the obvious issues by running the dev server, identify 
where things go wrong and repair them until the project software is 
mostly running with the Newname model. You may not get it to run but the 
dev server should not identify too many issues. Note, you may get the 
odd ProgrammingError - relation "Oldname" does not exist. Don't worry 
too much because you haven't renamed the table yet.


4. Create an empty migration using the --empty flag

5. Edit the empty operations list like this ...

operations = [
migrations.RenameModel('Oldname', 'Newname')
migrations.AlterModelTable('Newname', 'appname_newname'),
]

6. migrate

Note, you will probably need to or perhaps should delete stale content 
types at the end of the migration.


7. Run all unit tests

Thank you Sir Andrew and Django

Hope this helps someone

Mike


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/56C19073.5090505%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.