Apache Double Slash Help

[Jesus Ignacio Gómez Pérez]

 I am part of a colaborative initiative to develop software on Django, 
currently i'm working with Apache and Oscar Framework and i'm having 
troubles with the following request URI "
*dashboard/content-blocks/page//asistenciaMedica/*", which returns a 404 
code from Django url router which translate this URI to this one "
*/dashboard/content-blocks/page/asistenciaMedica/*", as you can see the URI 
has an extra slash on the "*/page//asistenciaMedica/*" section, i can't 
change the application behavior  because it is part of the framework 
mentioned above, so my doubt is the following:

How to configure Apache server to accept double slash and/or how to prevent 
the Django's url router to translate this special characters?

I would be grateful for your reply.

Regards.

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/19aa050e-6b8f-4640-b968-a0ed81e63d83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the ideal web server to use with Django?

[Marc Aymerich]

On Fri, May 15, 2015 at 10:33 AM, Tom Evans  wrote:
> On Thu, May 14, 2015 at 4:18 PM, Marc Aymerich  wrote:
>> On Thu, May 14, 2015 at 11:26 AM, Tom Evans  wrote:
>>> On our app servers we typically use Apache with worker MPM and
>>> mod_wsgi, although we have a few nginx+uwsgi sites, and I would dearly
>>> love some time to play around with a circusd + chausette + celery
>>> setup.
>>
>>
>> Hi Tom,
>> never heard about circusd and chaussette, but it sounds interesting.
>>
>> I believe the advantage of this setup pays when you have several
>> independent low-traffic applications, because you don't want all of
>> them to have preforked wsgi worker processes, not even the master
>> process. I think uwsgi can do that (emperor mode, cheaper subsystem),
>> but circusd will allow you to do the same which celery (celery needs
>> at least one master per pool). Is this the main point? I'm asking
>> because I can only find just a couple of blogposts and the
>> documentation is concise, neither mention the real tangible advantage
>> over traditional deployments.
>>
>
> There are few very cool things I like about circusd + chaussette,
> chausette allows you to run over a unix socket, and this allows
> circusd to easily spin up a new backend (with different code) and
> transfer requests to that unix socket, whilst leaving the old backend
> still running.
>
> This means zero downtime when doing a code upgrade, and instant
> failback to the old application if for some reason you don't like what
> was pushed.
>
> The second thing is that circusd is a process manager like
> supervisord, but it allows for dynamic operation - you can run celery
> worker processes underneath it, and spin up/spin down worker processes
> as you see fit to allow for load.
>
> The third is that circusd is accessed by a web interface, which allows
> for simple day to day use and also simplifies how admins and sysadmins
> can interact with it. Its very easy for our sysadmins to control
> things they can just fire http requests at.
>

thanks Tom, that is really cool, I really appreciated your comments on this!


-- 
Marc

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2BDCN_t886rR7b88H7oBYXGJTUBFA0wsxe9c6p8vK4G_7b2d9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CSRF Verification error appeared after I changed DNS ver2

[Jun Tanaka]

Hi, I got the same kind of an error as below.  CSRF Verification error 
appeared after I changed DNS
https://groups.google.com/forum/#!msg/django-users/dQXdPeAd6Fg/wFsEG03Qeu0J
And there is no solution written in there. Hope someone can help me.

Versions
Djagno 1.6
python2.7

In my case, I got u'CSRF_COOKIE' instead of 'csrf' in request.

I appreciate any solution for this issue.

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/11b39fbc-6834-4f41-ba9a-502d464071bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improve Performance in Admin ManyToMany

[Timothy W. Cook]

On Fri, May 15, 2015 at 7:25 AM, Erik Cederstrand  wrote:

>
> > I wonder if there is another approach that I can use to solve this?
>
> Does the suggestion to append select_related() / prefetch_related() to the
> queryset in your admin view not work?
>

​If I implemented it correctly, it doesn't have any effect.  I ​get the
same number of queries reported by DjDT and effectively the same amount of
time.

The model called Cluster is the most egregious.
Model:

*class Cluster(Item):*
*"""*
*The grouping variant of Item, which may contain further instances of
Item, in an ordered list. This*
*provides the root Item for potentially very complex structures.*
*"""*
*cluster_subject = models.CharField(_('cluster
subject'),max_length=110, help_text="Enter a text name for this subject of
this cluster.")*
*clusters = models.ManyToManyField('Cluster',help_text="Select zero or
more Clusters to include in this Cluster. You cannot put a Cluster inside
itself, it will be ignored if you select itself.", blank=True)*
*dvboolean = models.ManyToManyField(DvBoolean,
related_name='%(class)s_related', help_text="Select zero or more booleans
to include in this Cluster.", blank=True)*
*dvuri = models.ManyToManyField(DvURI,
related_name='%(class)s_related', help_text="Select zero or more uris to
include in this Cluster.", blank=True)*
*dvstring = models.ManyToManyField(DvString,
related_name='%(class)s_related', help_text="Select zero or more strings to
include in this Cluster.", blank=True)*
*dvcodedstring = models.ManyToManyField(DvCodedString,
related_name='%(class)s_related', help_text="Select zero or more coded
strings to include in this Cluster.", blank=True)*
*dvidentifier = models.ManyToManyField(DvIdentifier,
related_name='%(class)s_related', help_text="Select zero or more
identifiers to include in this Cluster.", blank=True)*
*dvparsable = models.ManyToManyField(DvParsable,
related_name='%(class)s_related', help_text="Select zero or more parsables
to include in this Cluster.", blank=True)*
*dvmedia = models.ManyToManyField(DvMedia,
related_name='%(class)s_related', help_text="Select zero or more media
items to include in this Cluster.", blank=True)*
*dvordinal = models.ManyToManyField(DvOrdinal,
related_name='%(class)s_related', help_text="Select zero or more ordinals
to include in this Cluster.", blank=True)*
*dvcount = models.ManyToManyField(DvCount,
related_name='%(class)s_related', help_text="Select zero or more counts to
include in this Cluster.", blank=True)*
*dvquantity = models.ManyToManyField(DvQuantity,
related_name='%(class)s_related', help_text="Select zero or more quantity
items to include in this Cluster.", blank=True)*
*dvratio = models.ManyToManyField(DvRatio,
related_name='%(class)s_related', help_text="Select zero or more ratios to
include in this Cluster.", blank=True)*
*dvtemporal = models.ManyToManyField(DvTemporal,
related_name='%(class)s_related', help_text="Select zero or more temporal
items to include in this Cluster.", blank=True)*

*def __str__(self):*
*return self.prj_name.prj_name + ":" + self.cluster_subject*




Model Admin:

*class ClusterAdmin(admin.ModelAdmin):*
*list_filter = ['prj_name__rm_version__version_id','prj_name',]*
*search_fields = ['cluster_subject','ct_id']*
*ordering = ['prj_name','cluster_subject']*
*actions = [make_published, unpublish, copy_cluster]*
*readonly_fields = ['published','schema_code','xqr_code','xqw_code',]*
*filter_horizontal =
['dvboolean','dvuri','dvstring','dvcodedstring','dvidentifier','clusters','dvparsable','dvmedia','dvordinal','dvtemporal','dvcount','dvquantity','dvratio',]*
*form = ClusterAdminForm*

*def formfield_for_many_to_many(self, db_field, *args, **kwargs):*
*formfield = super(ClusterAdmin,
self).formfield_for_many_to_many(db_field, *args, **kwargs)*
*if db_field.name  in
['cluster','dvboolean','dvuri','dvstring','dvcodedstring','dvidentifier','dvparsable','dvmedia',*
*
 'dvordinal','dvcount','dvquantity','dvratio','dvtemporal']:*
*formfield.queryset =
formfield.queryset.select_related('project')*
*return formfield*



​Each of the ManyToMany references have this in their model:


​ *   def __str__(self):*
*return self.prj_name.prj_name + ":" + self.data_name*
*​*


​Thoughts?


--Tim​



Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 

Re: CSRF Verification error appeared after I changed DNS

[Jun Tanaka]

I got the same kind of an error.

In my case, I got u'CSRF_COOKIE' instead of 'csrf' in request.

I appreciate any solution for this issue.



2013年1月9日水曜日 8時44分49秒 UTC+9 Saqib Ali:
>
>
> Hi.
>
> I have been using Django successfully for a few days now. I was running my 
> django application on an Amazon Web Service machine. 
> I was assigned some arbitrary DNS name that looked like this: 
> http://ec2-XXX.XXX.XXX.XXX.compute-1.amazonaws.com.
> My Django app was working find with my model and several views with 
> templates.
>
> Last night, I went out and bought a real DNS name from register.com and 
> have that DNS name now pointing to my django application.
> Since I made that change however, when I submit my django form, I get the 
> following CSRF error:
>
>
> Forbidden (403)
>
> CSRF verification failed. Request aborted.
>
>
>
> I tried clearing the cookies in my browser, but that didn't help. I even 
> tried it from other machines that I had never tried before. But still the 
> same problem.
>
> Why did assigning a new DNS name for this IP address cause this CSRF 
> error? And how do I get rid of it?
>
>
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/219853c2-2919-43c2-b1e1-977bc542bbb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CSRF Verification error appeared after I changed DNS ver2

[Jun Tanaka]

Hi, I got the same kind of an error as below.  CSRF Verification error 
appeared after I changed DNS
https://groups.google.com/forum/#!msg/django-users/dQXdPeAd6Fg/wFsEG03Qeu0J
And there is no solution written in there. Hope someone can help me.

Versions
Djagno 1.6
python2.7


-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/92ba6507-37ab-44b7-9ec1-f51c193d7552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DjangoCon US: Call For Proposals: Last Call

[Jeff Triplett]

Hello everyone,

We are down to our last call for talk and tutorial submissions for 
DjangoCon US this year.

If you have a talk or tutorial idea then I would encourage you to consider 
submitting 
one today  before it's too late 
because we will not be extending the deadline this year. 

We will accept submissions until midnight Anywhere on Earth 
 today (May 15th).

Regards,

Jeff Triplett
Chair, DjangoCon US 2015
@webology / @djangocon

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/66aaecc7-c1f7-4a7f-bed7-5cc93195aeed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[Carl Meyer]

On 05/15/2015 09:14 AM, Andreas Kuhne wrote:
> You are getting it because someone has come to your server by
> entering www.g3suprimentos.com.br  in
> a browser. If you don't have that address in the allowed hosts setting,
> you will get the error you have received. 

Correct.

> If you don't want your server to show something
> for www.g3suprimentos.com.br , then
> the problem is not on your end, but rather the clients (it can be an
> incorrect DNS entry, or that someone has edited their hosts file). So
> you can't do anything to fix it.

Not true - in most cases you can fix it on the server side, but the
details depend on your server configuration. You need to configure
whatever front-end server is listening for the web requests to ignore
any requests coming in for a host name that you don't want your server
to respond to. If you're using Apache, this meand making sure that your
Django site is running in a name-based virtualhost (and not the default
one). If you're using nginx, it just means setting the server_name of
the server block to the hostname(s) you actually want to serve. Etc.

Carl

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5556116D.5090806%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[François Schiettecatte]

There is nothing to debug, Django is just telling you that it is getting an 
invalid request where the ‘Host:’ header does not match the host name the 
application is expecting. Django will reject such requests and warn you about 
them:

https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts

François

> On May 15, 2015, at 11:10 AM, frocco  wrote:
> 
> The problem is I do not know how to debug this issue.
> 
> On Tuesday, March 17, 2015 at 9:17:15 AM UTC-4, frocco wrote:
> SuspiciousOperation: Invalid HTTP_HOST header (you may need to set 
> ALLOWED_HOSTS): www.g3suprimentos.com.br
> 
> I keep getting this error from time to time.
> 
> Is someone trying to hack my site?
> 
> 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/e148d1ef-de61-418a-a821-d52dd81e5591%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/F7C2CF63-2672-4366-8FA5-4E546950C054%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[Andreas Kuhne]

You are getting it because someone has come to your server by entering
www.g3suprimentos.com.br in a browser. If you don't have that address in
the allowed hosts setting, you will get the error you have received.

If you don't want your server to show something for www.g3suprimentos.com.br,
then the problem is not on your end, but rather the clients (it can be an
incorrect DNS entry, or that someone has edited their hosts file). So you
can't do anything to fix it.

Regards,

Andréas



2015-05-15 17:10 GMT+02:00 frocco :

> The problem is I do not know how to debug this issue.
>
> On Tuesday, March 17, 2015 at 9:17:15 AM UTC-4, frocco wrote:
>>
>> SuspiciousOperation: Invalid HTTP_HOST header (you may need to set
>> ALLOWED_HOSTS): www.g3suprimentos.com.br
>>
>> I keep getting this error from time to time.
>>
>> Is someone trying to hack my site?
>>
>> 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/e148d1ef-de61-418a-a821-d52dd81e5591%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALXYUb%3Df1M%3DYALLhqupKkiZ550XZDg%3DVna3HN1L1pxQ%2B%3D-wpMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Invalid HTTP_HOST, can someone explain why I am getting this?

[frocco]

The problem is I do not know how to debug this issue.

On Tuesday, March 17, 2015 at 9:17:15 AM UTC-4, frocco wrote:
>
> SuspiciousOperation: Invalid HTTP_HOST header (you may need to set 
> ALLOWED_HOSTS): www.g3suprimentos.com.br
>
> I keep getting this error from time to time.
>
> Is someone trying to hack my site?
>
> 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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e148d1ef-de61-418a-a821-d52dd81e5591%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: best way change template base my app

[Ilya Kazakevich]

You also may use widgets instead of "extends": 
http://sniplates.readthedocs.org/en/latest/


On Friday, May 15, 2015 at 6:50:40 AM UTC+3, sacrac wrote:
>
> Thank Andre Luis :)
>
> On Wed, May 13, 2015 at 1:41 PM, André Luiz  > wrote:
>
>> extends should always be on first line of file and it accepts a variable 
>> as argument so you can define which template should be used on your view.
>>
>> # views.py
>> def home(request):
>> if request.session.type == 1:
>>  base = 'base.html'
>> else:
>> base = 'base_other.html'
>>
>> context = {
>> 'base': base,
>> }
>>
>> return render(request, 'template.html', context)
>>
>> # template.html
>> {% extends base %}
>>
>> if you need it on every template maybe you should use a context processor 
>> to define your base variable.
>>
>> 2015-05-13 15:11 GMT-03:00 carlos :
>>
>>> Hi, is posible change my base template with if tag
>>> example:
>>>
>>> {% if request.session.type = '1' %}
>>> {% extends "base.html"%}
>>> {% else %}
>>>{% extends "base_other.html"%}
>>> {%endif%}
>>>
>>> i have a error like that
>>>
>>> TemplateSyntaxError at /monito/cult/
>>>
>>> Invalid block tag: 'endif'
>>>
>>>
>>> will to do change the base template my app
>>>
>>> Cheers
>>>
>>> -- 
>>> 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 http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/CAM-7rO3DONtDe_d%2BHeBef446Mr%3DvSiKK7z_W8pyNyPq7Pbt3PA%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  -- 
>> 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 http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/CAL6LtmfZTMpfG%3Djh_uMtp63hZ%2BDsmz92_8UP81x0zuGfqp%2BO0w%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fd0c960d-98d6-44aa-9fd4-8b722cc43c00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the ideal web server to use with Django?

[Ilya Kazakevich]

Hi.

I believe the best installation is Apache + wsgi and nginx for static. 

In some scenarios Apache performance may be your bottleneck, but:
1) there are a lot of ways to tune it. Read about "Multi-Processing 
Modules" for example.
2) 99% of web applications do have different bottlenecks, not the web 
server.
3) really huge installations should use clusters hence should be scalable 
horizontally. In such scenarios web server performance is not an issue 
(unless you work for Google or Facebook) :)


On Wednesday, May 13, 2015 at 4:15:18 AM UTC+3, akshat wrote:
>
> I am new to Django. I am building a app which will have to handle several 
> concurrent requests. Which web server is suitable for this? I have read 
> that Apache's performance degrades on high load.
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/eed0c413-9cf6-4ceb-91ef-95a85c42ec3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

migrate primary key changes

[raviteja nandula]

Hi All,

I have created a model with primary key, later i have removed the primary 
key and used default `id` as primary key

When i tried to migrate it is throwing error with multiple primary keys 
defined

Before running migrate i have executed on MySQL command interface

"ALTER TABLE `table_name` DROP PRIMARY KEY;"


After this i re run the migrate. It executed perfectly.


Thanks
Ravi Teja N

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c1704bca-2c3a-4715-b507-8d250aa41960%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "RuntimeError: Error creating new content types."

[Pedram Negahdar]

Same problem nothing is working!!

On Wednesday, May 6, 2015 at 6:07:45 AM UTC-4, Max Usachev wrote:
>
> Try to migrate auth application first, and then others:
> manage.py migrate auth
> manage.py migrate
>
> среда, 29 апреля 2015 г., 14:12:33 UTC+3 пользователь Shubham Goyal 
> написал:
>>
>> Facing the same problem. Any leads..??
>>
>> On Saturday, April 18, 2015 at 2:38:56 AM UTC+5:30, Christophe Pettus 
>> wrote:
>>>
>>> Well, django_content_type.name definitely in my database. :)  This is a 
>>> project that was migrated from 1.6. 
>>>
>>> The underlying exception was a null value complaint about 
>>> django_content_type.name; it appears as though (on the production 
>>> database) it thought that the migration to remove had been applied, but in 
>>> fact had not been. 
>>>
>>> On Apr 17, 2015, at 1:25 PM, Tim Graham  wrote: 
>>>
>>> > The contenttypes name column was removed in Django 1.8. Could you 
>>> retrieve the underlying exception before the RuntimeError is raised? 
>>> > 
>>> > On Friday, April 17, 2015 at 2:55:07 PM UTC-4, Christophe Pettus 
>>> wrote: 
>>> > Digging into this a bit more, the specific exception is that it is 
>>> trying to insert a contenttypes row with a null 'name' value. 
>>> > 
>>> > The code in question is doing a get_or_create() on the contenttype 
>>> object.  I assume it should be picking up the name from the name @property 
>>> on the ContentType model, but I don't see that ever actually being called. 
>>> > 
>>> > 
>>> > On Apr 17, 2015, at 11:24 AM, Christophe Pettus  
>>> wrote: 
>>> > 
>>> > > On Django 1.8, I'm encountering this error when attempting to apply 
>>> migrations on the production system.  What's interesting is that it works 
>>> fine on the dev system, and inspecting the django_migrations table, I don't 
>>> see any (meaningful) differences between them (error text below). 
>>> > > 
>>> > > There was a model added to the "catalog" application which is not 
>>> being created in django_content_type. 
>>> > > 
>>> > > Manually migrating contenttypes individually generates the same 
>>> error. 
>>> > > 
>>> > > -- 
>>> > > 
>>> > > $ python manage.py migrate 
>>> > > Operations to perform: 
>>> > >  Synchronize unmigrated apps: staticfiles, util, treebeard, 
>>> messages, office 
>>> > >  Apply all migrations: info, customers, sessions, admin, 
>>> contenttypes, auth, sites, catalog, coming_soon, orders 
>>> > > Synchronizing apps without migrations: 
>>> > >  Creating tables... 
>>> > >Running deferred SQL... 
>>> > >  Installing custom SQL... 
>>> > > Running migrations: 
>>> > >  Rendering model states... DONE 
>>> > >  Applying auth.0006_require_contenttypes_0002... OK 
>>> > > Traceback (most recent call last): 
>>> > >  File "manage.py", line 10, in  
>>> > >execute_from_command_line(sys.argv) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>>>  
>>> line 338, in execute_from_command_line 
>>> > >utility.execute() 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>>>  
>>> line 330, in execute 
>>> > >self.fetch_command(subcommand).run_from_argv(self.argv) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/base.py",
>>>  
>>> line 390, in run_from_argv 
>>> > >self.execute(*args, **cmd_options) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/base.py",
>>>  
>>> line 441, in execute 
>>> > >output = self.handle(*args, **options) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>>>  
>>> line 225, in handle 
>>> > >emit_post_migrate_signal(created_models, self.verbosity, 
>>> self.interactive, connection.alias) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/core/management/sql.py",
>>>  
>>> line 280, in emit_post_migrate_signal 
>>> > >using=db) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py",
>>>  
>>> line 201, in send 
>>> > >response = receiver(signal=self, sender=sender, **named) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py",
>>>  
>>> line 82, in create_permissions 
>>> > >ctype = 
>>> ContentType.objects.db_manager(using).get_for_model(klass) 
>>> > >  File 
>>> "/home/tbc/environments/fugu/local/lib/python2.7/site-packages/django/contrib/contenttypes/models.py",
>>>  
>>> line 78, in get_for_model 
>>> > >"Error creating new content types. Please make sure contenttypes 
>>> " 
>>> > > RuntimeError: Error creating new content types. Please make sure 
>>> contenttypes is migrated before trying to migrate apps individually. 
>>> > > -- 
>>> > > 

Re: Improve Performance in Admin ManyToMany

[Erik Cederstrand]

> Den 14/05/2015 kl. 22.19 skrev Timothy W. Cook :
> 
> That is exactly the problem Simon.  Everyone of those models reference a 
> model called Project.  I did this so that when the items are displayed in the 
> selects, the user knows which project it is from.  In the interim I guess 
> I'll remove the call to Project from the __str__ 
> 
> I wonder if there is another approach that I can use to solve this?  

Does the suggestion to append select_related() / prefetch_related() to the 
queryset in your admin view not work?

Erik

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/A395D2BC-D3B1-40C5-84B7-678A070DFCB6%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Scaling/Parallel patterns for a View executing complex database transaction

[mesulphur]

Hi Stephen,

We did try with Redis (instead of memcached) but the memory usage Redis 
is 2.5x-3x the volume of data, the economics of having entire data in 
memory then breaks down. Also because of the large degree of 
variation/random access patterns, there is little benefit in using an 
LRU cache layer.


Thanks!


On Friday 15 May 2015 10:16 AM, Stephen J. Butler wrote:

If it's just key-value storage, adding a memcached layer sounds like a
good thing to investigate. Do the tuples frequently change?

On Thu, May 14, 2015 at 11:30 PM, Me Sulphur  wrote:

Hi Russ,

Thanks! While there are some pointers that we can pick up from your answer,
let me add some more details.

* It is a large key-value pair table (approaching ~ 1 bn rows) with an MD5
key and JSON  for value. The look ups depend on the business logic but are
necessary. Nevertheless, there are no more than 10-12 queries executed by
combining key look ups using WHERE IN queries and pg is surprisingly good
with IN queries.

* Pre-computation is theoretically possible but the permutations can be very
limiting. Over the top of my head, I think it will be M^n where M and n are
very large (and growing) integers.

* You are right, celery+polling can be done but the API is already deployed
and in use in environments where there is strong resistance to rework a code
base which is stable and changing them (consumers of the API) is beyond
control.


Thanks!


On Friday, 15 May 2015 06:06:57 UTC+5:30, Russell Keith-Magee wrote:


On Thu, May 14, 2015 at 6:03 PM, Me Sulphur  wrote:

Stack: Django 1.7 + Postgres 9.3 + Linux (No caching)

Our application has a view which is called/executed very frequently. The
view receives, parses and responds a JSON.

In between request and response, there are about 3-5 inserts and around
1200-5000 look ups depending upon some if..else business logic. At around
2-4 seconds the view is very slow.

However, a lot of the look ups (which are the bottlenecks) can be
parallelized. But I do not know how can I do the same within a
request-response cycle.

If it was a web UI, I could use celery+polling, since it a
machine-machine API call, the parallelisation has to be possible within a
View's life cycle.

If parallelisation is not possible, what alternatives do I have for
scaling and reducing response time.


The short answer is "it depends".

There isn't a single answer - everything will depend on the specifics of
your problem space. All I can offer is some vague suggestions of places you
might be able to look for some extra speed.

  * Do you *really* need to do 1200-5000 lookups? It's faster to do 1 query
returning 10 rows than 10 queries returning 1 row each. Can you optimise the
queries on the database to minimise the number of queries needed? Depending
on circumstances, it may even be faster to do 1 query returning 15 rows, and
then post-process in the view to throw away the 5 rows you don't need.

  * Better still - can you optimize the database structure so that
1200-5000 calls aren't needed? Modern relational databases are *really* good
at query optimisation - if you give it the right query, and the right
database.

  * Can you work your algorithm another way? In a previous job, I worked on
a tool that would look at a database of thousands of news articles received
in a given day, and then, for each of thousands of users, work out which
articles were "interesting" so they could be sent out in a daily alert
email. The obvious algorithm for this is "for user in users:
find_articles(user)" - but, for a variety of reasons, it turned out that
doing "for article in articles: find_users(article)" was almost 2 orders of
magnitude of faster. The less obvious algorithm allowed much greater
caching, and massively cut down the number of queries that were required.
The tradeoff was a lot more memory (memory vs speed is almost always the
tradeoff), and it wasn't only faster if you computed the results for *all*
users at the same time - but this was an daily offline process, so these
were limitations we were willing to accept.

  * To that end - is there anything that can be precomputed? Can you cache
pieces of the response? Is there anything you can put into a memory store,
rather than the database. Databases are great, but if you have a small
amount of frequently re-used, easily keyed data, it may be better to put
that data into a location where it can be obtained quickly, rather than
hitting the database.

  * If you *must* parallelize, and your algorithm is conducive to it,
threads are probably your best option - work out what part of your algorithm
can be parallelized, and put each part in a thread, and merge the results
once all the threads complete. If you're on Python 3, look into the
concurrent.futures module (or the "futures" module if you're on Python 2) to
help make this easier to manage. However, threads aren't magic fairy dust -
my "limited knowledge of your situation" guess is that 

possible bug - CharField accepts string as max_length

[Santiago L]

Hi,

I think that I have found a bug on the system check: it accepts a string as 
value for CharField.max_length argument.

It happens only if the string can be converted to int (e.g. 
max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo').

from django.db import models

class Foo(models.Model):
bar = models.CharField(max_length='16')


# following code raises an Exception
obj = Foo(bar='lorem ipsum')
obj.clean_fields()


Traceback:
>>> obj = Foo(bar='lorem ipsum')
>>> obj.clean_fields()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py", 
line 1167, in clean_fields
setattr(self, f.attname, f.clean(raw_value, self))
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
line 589, in clean
self.run_validators(value)
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
line 541, in run_validators
v(value)
  File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
line 280, in __call__
if self.compare(cleaned, self.limit_value):
  File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
line 319, in 
compare = lambda self, a, b: a > b
TypeError: unorderable types: int() > str()

Best regards,

Santiago

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the ideal web server to use with Django?

[Avraham Serour]

>chausette allows you to run over a unix socket, and this allows
circusd to easily spin up a new backend (with different code) and
transfer requests to that unix socket, whilst leaving the old backend
still running.

This was the killer feature that I started using uwsgi, you can reload your
new django code without uwsgi closing the socket, in the worst case some
requests may feel a little delay but won't feel any downtime

I once even did a crazy thing: a form that updated and reload its own
django code (git pull and uwsgi reload), it worked great, user would click
on the button to update the system, the request would come and the user
would get the updated version on reload (because form response is redirect)

my only problem was doing the same trick on cygwin, but that's another story

On Fri, May 15, 2015 at 11:33 AM, Tom Evans 
wrote:

> On Thu, May 14, 2015 at 4:18 PM, Marc Aymerich 
> wrote:
> > On Thu, May 14, 2015 at 11:26 AM, Tom Evans 
> wrote:
> >> On our app servers we typically use Apache with worker MPM and
> >> mod_wsgi, although we have a few nginx+uwsgi sites, and I would dearly
> >> love some time to play around with a circusd + chausette + celery
> >> setup.
> >
> >
> > Hi Tom,
> > never heard about circusd and chaussette, but it sounds interesting.
> >
> > I believe the advantage of this setup pays when you have several
> > independent low-traffic applications, because you don't want all of
> > them to have preforked wsgi worker processes, not even the master
> > process. I think uwsgi can do that (emperor mode, cheaper subsystem),
> > but circusd will allow you to do the same which celery (celery needs
> > at least one master per pool). Is this the main point? I'm asking
> > because I can only find just a couple of blogposts and the
> > documentation is concise, neither mention the real tangible advantage
> > over traditional deployments.
> >
>
> There are few very cool things I like about circusd + chaussette,
> chausette allows you to run over a unix socket, and this allows
> circusd to easily spin up a new backend (with different code) and
> transfer requests to that unix socket, whilst leaving the old backend
> still running.
>
> This means zero downtime when doing a code upgrade, and instant
> failback to the old application if for some reason you don't like what
> was pushed.
>
> The second thing is that circusd is a process manager like
> supervisord, but it allows for dynamic operation - you can run celery
> worker processes underneath it, and spin up/spin down worker processes
> as you see fit to allow for load.
>
> The third is that circusd is accessed by a web interface, which allows
> for simple day to day use and also simplifies how admins and sysadmins
> can interact with it. Its very easy for our sysadmins to control
> things they can just fire http requests at.
>
> Cheers
>
> Tom
>
> --
> 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAFHbX1Kekp9cNqqcZPjxfpWgGS%2BxGhuaaE9VT35Hd79S%3Dv8kbg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tKVfSGznv5NNzBfqPkakCn_oofaDe28Nf6Nmb6mXP2zoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the ideal web server to use with Django?

[Tom Evans]

On Thu, May 14, 2015 at 4:18 PM, Marc Aymerich  wrote:
> On Thu, May 14, 2015 at 11:26 AM, Tom Evans  wrote:
>> On our app servers we typically use Apache with worker MPM and
>> mod_wsgi, although we have a few nginx+uwsgi sites, and I would dearly
>> love some time to play around with a circusd + chausette + celery
>> setup.
>
>
> Hi Tom,
> never heard about circusd and chaussette, but it sounds interesting.
>
> I believe the advantage of this setup pays when you have several
> independent low-traffic applications, because you don't want all of
> them to have preforked wsgi worker processes, not even the master
> process. I think uwsgi can do that (emperor mode, cheaper subsystem),
> but circusd will allow you to do the same which celery (celery needs
> at least one master per pool). Is this the main point? I'm asking
> because I can only find just a couple of blogposts and the
> documentation is concise, neither mention the real tangible advantage
> over traditional deployments.
>

There are few very cool things I like about circusd + chaussette,
chausette allows you to run over a unix socket, and this allows
circusd to easily spin up a new backend (with different code) and
transfer requests to that unix socket, whilst leaving the old backend
still running.

This means zero downtime when doing a code upgrade, and instant
failback to the old application if for some reason you don't like what
was pushed.

The second thing is that circusd is a process manager like
supervisord, but it allows for dynamic operation - you can run celery
worker processes underneath it, and spin up/spin down worker processes
as you see fit to allow for load.

The third is that circusd is accessed by a web interface, which allows
for simple day to day use and also simplifies how admins and sysadmins
can interact with it. Its very easy for our sysadmins to control
things they can just fire http requests at.

Cheers

Tom

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1Kekp9cNqqcZPjxfpWgGS%2BxGhuaaE9VT35Hd79S%3Dv8kbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.