Re: Limit a view to superuser only

[Derek]

Bear in mind that unless you are running Django's built-in dev server, you 
will need to restart your production server for changes to propagate.

On Sunday, 19 November 2017 17:21:28 UTC+2, yingi keme wrote:
>
> All of a sudden and out of the blue, it just worked. I had the re-run my 
> server
>
> On Sunday, November 19, 2017 at 5:54:11 AM UTC-8, Jani Tiainen wrote:
>>
>> Hi.
>>
>> Could you paste the full traceback here because having an OSError sounds 
>> like there is is something else wrong in your system.
>>
>> On 19 Nov 2017, at 15.22, yingi keme  wrote:
>>
>> I have a function that i want to be accessed only if the user is a 
>> supersuser.
>>
>> I have tried this
>>
>> from django.contrib.admin.views.decorators import staff_member_required
>>
>> @staff_member_required
>> def my_view(request):
>> template_name = 'Core\CustomizedAdmin.html'
>> return render(request, template_name)
>>
>>
>> What happens is that when i try to access this view, it directs me to the 
>> default login admin page. 
>> And then when i login as a superuser, it gives an OSError invalid 
>> argument:
>>
>> I expected that after login in as a superuser it will redirect to the 
>> Page i want.
>>
>> Am i doing it the wrong way?
>>
>> Is there an alternative way to Limit a view to superuser only?
>>
>> -- 
>> 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/fc05e300-5e71-4bc5-b388-2996c5b8bb0a%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/426f7c53-318f-4137-992f-8281627c2efa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some newbie questions on CBVs and FBVs

['Simon Connah' via Django users]

 Hi,
First of all thank you very much for the reply. It was very useful. I'll 
re-read the documentation and see what I was missing out on.
The get_queryset() method was a very useful hint. That may well solve the issue 
I was having.
Simon.On Friday, 24 November 2017, 06:20:35 GMT, Matemática A3K 
 wrote:  
 
 

On Thu, Nov 23, 2017 at 8:49 PM, 'Simon Connah' via Django users 
 wrote:

Hi everyone,
First of all sorry for the newbie questions it has been a long time since I 
used Django and I think I have forgotten just about everything I once knew.
I'm working on a user app for a website. I can't use the built in user model as 
I need a little more flexibility and the ability to grow in the future if 
required.
Basically I have three problems.
1) I need some views to be limited to the user who created the view.

Users do no create Views, what you are meaning is the objects "created" by the 
user (or objects attributed or associated to the user if you want to be even 
more precise)
 
 For instance I have an UpdateUser view and I only want the currently logged in 
user to be able to change their own user model data. So say I have the username 
"djangouser" and I go to UpdateView the only row in the database that I can 
change on the database server is the one with the username "djangouser". I'm 
not sure what the best way to handle this problem is?

Set the queryset attribute of the UpdateView to 
User.objects.filter(name=self.request.user) or override the get_queryset() 
method in the view:def get_queryset(self):
base_qs = super(YourUpdateView, self).get_queryset()
return 
base_qs.filter(user=self.request.user)https://stackoverflow.com/questions/8594759/django-updateview-restrict-per-user
https://docs.djangoproject.com/en/1.11/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.get_queryset


I could do it manually in a function based view without any problem but I find 
CBVs to be really hard to customise when you want to do something that they 
were not specifically designed to do.

Overriding the queryset is a common pattern in CBV :)
 
 At that point I just end up writing a FBV instead and doing it all myself as 
it is quicker than trying to figure out all the mixins and all the methods of 
the class.


I must be missing something simple with CBVs. Any help would be appreciated 
with this :).
 You should read the whole topic:
https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/ 
and then read the 
reference:https://docs.djangoproject.com/en/1.11/ref/class-based-views/mixins/


2) In FBVs you get passed a variable to the function with the URL conf 
variables, for instance: (path('/blah//', view, name='blah') would 
result in the FBV recieving a username parameter. Where are these variables 
stored when using a CBV?

You should read the topic :)
 

3) Is it considered bad practice to use FBVs in Django?

IMO, no :)
 
 I just find them so much easier and quicker to write. I know that CBVs result 
in less code duplication but I find I constantly need the Django docs open to 
see what each CBV supports and which methods it has available. Where as with 
FBVs I just write the code and everything works.


CBV is a pattern, if you don't embrace it, it may get in your way :)
 
Anyway, thank you for any help :).
Simon.

-- 
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+unsubscribe@ 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/1609714478. 2477254.1511480996285%40mail. yahoo.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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2BFDnh%2BYZfaoRPAvZCeGr3L2uz6W%3DTgcVChAwJV%3DCmhC4Y9%2BQA%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 

Re: Django Channels and multi-tenant will this be a world of hurt?

[Andrew Godwin]

Your assumptions all seem correct. Also consider that the security model of
WebSockets is... interesting, so securing a multi-tenant setup is going to
require a bit more work than you would merely doing the same for HTTP
requests.

There are other non-Channels options around if you want to look into them,
but I suspect they'll all have similar architectural challenges.

Andrew

On Fri, Nov 24, 2017 at 3:09 PM, Filbert  wrote:

> Running multi-tenant site using a fork of Django tenant schemas with tens
> of web servers and thousands of tenants
>
> Piloting a project to implement Channels for real-time notifications, etc.
>
> I want to confirm these assumptions:
>
> 1. Channels really has no support for multi-tenant, I will have to roll my
> own.
> 2. Since uWSGI is serving us well and (at this point) I wouldn't trust
> Daphne to serve HTTP, I've got split paths in NGinx for uWSGI and ASGI.
> 3. We are running RabbitMQ, so we have to cluster it and implement
> channels using asgi_rabbitmq (Redis would just add yet another moving part)
> 4. Plan on significant additional resource requirements on the web server
> and serious scaling challenges.
>
> Are their any other non-Channels options, or is it the really the only
> game in town?
>
> 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/aae2725b-d873-40fd-ae09-d1668ab9e727%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFwN1urh-Mb%3D2ZRtwyvZPh9CQoUDHrqN30yQUxhUd5GbUT8XfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django Channels and multi-tenant will this be a world of hurt?

[Filbert]

Running multi-tenant site using a fork of Django tenant schemas with tens 
of web servers and thousands of tenants

Piloting a project to implement Channels for real-time notifications, etc.

I want to confirm these assumptions:

1. Channels really has no support for multi-tenant, I will have to roll my 
own.
2. Since uWSGI is serving us well and (at this point) I wouldn't trust 
Daphne to serve HTTP, I've got split paths in NGinx for uWSGI and ASGI.
3. We are running RabbitMQ, so we have to cluster it and implement channels 
using asgi_rabbitmq (Redis would just add yet another moving part)
4. Plan on significant additional resource requirements on the web server 
and serious scaling challenges.

Are their any other non-Channels options, or is it the really the only game 
in town?

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/aae2725b-d873-40fd-ae09-d1668ab9e727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange query when using annotate and count

[Cristiano Coelho]

Hello Simon,

You are right, the score is really not meant to be attached so a custom 
lookup might work, if it wasn't for the issue that an order_by clause would 
fail without the annotation. 

So it seems it's either update and duplicate a lot of code or find a very 
ugly work around, I was hoping I missed some flag or implementation detail 
on the custom function to tell the query builder to avoid all the grouping 
and subquery stuff, will research more...


El viernes, 24 de noviembre de 2017, 14:39:27 (UTC-3), Simon Charette 
escribió:
>
> Hello Cristiano,
>
> If you are solely using this annotation for querying purpose, that means 
> you are
> not expecting a `score` attribute to be attached to your `Vulnerability` 
> instances,
> you could try defining your function as a lookup on CharField/TextField 
> instead.
>
> You could then use it only when required by passing a tuple of values to 
> it.
>
> e.g.
>
> Vulnerability.objects.filter(summary__wordsimilarity_gt=('test', 
> threshold))
>
> If you need the value annotated I'm afraid the best solution would be to 
> use
> a custom paginator class. You could give a try at detecting whether or not
> an annotation is referenced before removing it from query.annotations and
> report your finding on the aforementioned ticket but I expect this to be
> relatively hard to do correctly. Still it would make implementing `alias()`
> way easier and provide help for users in the situation as you.
>
> Best,
> Simon
>
> Le vendredi 24 novembre 2017 08:14:10 UTC-5, Cristiano Coelho a écrit :
>>
>> Hello Simon,
>>
>> That private API is good to know, but now that I think of it would still 
>> not work for me, since my queryset is passed to a paginator and that's the 
>> class that does both the count and actual queryset execution, so need a 
>> queryset that can have both the annotation but also clears it if count is 
>> called so it doesn't create the redundant sub queries.
>>
>> I'm wondering what's better, should I try to resolve this at the manager 
>> level overriding count? I feel like this might cause issues if the 
>> annotation is actually legit (ie with an aggregate) and it needs the 
>> subquery after all.
>> The other option is to subclass the paginator class with a special one 
>> that does this annotation clearing before running count.
>>
>> Even with these cases, if the annotated value is used later with a filter 
>> query I can't really simply removed, but the sub queries and extra function 
>> calls really doesn't make sense to be there when doing a count, so it seems 
>> that all the options are quite bad and hackish.
>>
>> Any other options?
>>
>>
>> El viernes, 24 de noviembre de 2017, 1:12:07 (UTC-3), Simon Charette 
>> escribió:
>>>
>>> Hello Cristiano,
>>>
>>> > Isn't there a way (even if it's hackish) to simply clear the 
>>> annotations (and order by)? I know querysets are smart enough to not 
>>> include the order by clause if there's a count.
>>>
>>> The ordering is cleared on `count()` because it shouldn't interfere with 
>>> the result in any way. You can clear annotations using 
>>> `queryset.query.annotations.clear()` but be aware that it is a private API 
>>> that could change under your feet. Make sure to make a copy of the queryset 
>>> (e.g. copy = queryset.all()) before performing this change as it will alter 
>>> the queryset in place.
>>>
>>> Best,
>>> Simon
>>>  
>>> Le jeudi 23 novembre 2017 22:41:41 UTC-5, Cristiano Coelho a écrit :

 Hello Simon, thanks for the response.

 The above code is just an example, the reason behind the annotate 
 because there's some complicated code that builds a queryset and annotates 
 it so it can easily be reused. It works fine 99% of the time except when 
 there's a count involved and it ends up being redundant. The solution 
 would 
 be to not annotate anything and replace the code in multiple places to add 
 the annotate call (or similar using a custom queryset or manager I guess), 
 but that's quite painful and will end up with a lot of duplicated code 
 since there's also an order_by that follows the annotate that needs to be 
 moved over as well

 Isn't there a way (even if it's hackish) to simply clear the 
 annotations (and order by)? I know querysets are smart enough to not 
 include the order by clause if there's a count.

 You could also suggest using two separate calls or a flag to pass down 
 to the internal code so it doesn't include the additional stuff, but that 
 wouldn't work since paginators accept only one query set for example and 
 internall uses it for both count and results.



 El viernes, 24 de noviembre de 2017, 0:05:29 (UTC-3), Simon Charette 
 escribió:
>
> Hello Cristiano,
>
> I understand your frustration but please avoid using the developer 
> mailing list
> as a second tier support channel. I suggest you try the IRC #django 
> 

Re: How do I make Django show the "user already exists" message when someone tries to register with an existing username?

[Tom Tanner]

Thanks for replying. Looks like it'll be easier for me to combine these 
into one view.

On Thursday, November 23, 2017 at 7:13:16 PM UTC-5, Tom Tanner wrote:
>
> My `urls.py` has this:
> url("^login_register/$", views.login_register, name="login_register"),
> url("^register/$", views.register, name="register"),
>
> `views.py` has this:
> def login_register(request, template="pages/login_register.html"):
>  '''
>  Display registration and login forms
>  '''
>  registration_form= RegisterForm()
>  return render(request, template, {"registration_form": registration_form
> })
>
>
>
>
> def register(request):
>  '''
>  Process user registration
>  '''
>  if request.method=="POST":
>   form= RegisterForm(request.POST)
>   print form.is_valid()
>   if form.is_valid():
>form.save()
>email= form.cleaned_data.get("email")
>raw_password= form.cleaned_data.get("password1")
>user= authenticate(username=email, password=raw_password)
>login(request, user)
>return redirect(home_slug())
>  else:
>   return redirect(reverse("login_register"))
>
>
> `login_register.html` form HTML looks like this:
>  Register
>  
>{% csrf_token %}
>{{ registration_form.as_p }}
>Register
>  
>
>
> When I fill out registration with an email that already exists, I get this 
> error: `ValueError: The view theme.views.register didn't return an 
> HttpResponse object. It returned None instead.`. That's because when 
> `form.is_valid()` is False, there is no return value. What do I need to 
> return so that the message on the Registration form states the email 
> already exists?
>
>
>

-- 
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/acd3f42f-9859-4c0c-8f00-e8147c0bbc2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange query when using annotate and count

[Simon Charette]

Hello Cristiano,

If you are solely using this annotation for querying purpose, that means 
you are
not expecting a `score` attribute to be attached to your `Vulnerability` 
instances,
you could try defining your function as a lookup on CharField/TextField 
instead.

You could then use it only when required by passing a tuple of values to it.

e.g.

Vulnerability.objects.filter(summary__wordsimilarity_gt=('test', threshold))

If you need the value annotated I'm afraid the best solution would be to use
a custom paginator class. You could give a try at detecting whether or not
an annotation is referenced before removing it from query.annotations and
report your finding on the aforementioned ticket but I expect this to be
relatively hard to do correctly. Still it would make implementing `alias()`
way easier and provide help for users in the situation as you.

Best,
Simon

Le vendredi 24 novembre 2017 08:14:10 UTC-5, Cristiano Coelho a écrit :
>
> Hello Simon,
>
> That private API is good to know, but now that I think of it would still 
> not work for me, since my queryset is passed to a paginator and that's the 
> class that does both the count and actual queryset execution, so need a 
> queryset that can have both the annotation but also clears it if count is 
> called so it doesn't create the redundant sub queries.
>
> I'm wondering what's better, should I try to resolve this at the manager 
> level overriding count? I feel like this might cause issues if the 
> annotation is actually legit (ie with an aggregate) and it needs the 
> subquery after all.
> The other option is to subclass the paginator class with a special one 
> that does this annotation clearing before running count.
>
> Even with these cases, if the annotated value is used later with a filter 
> query I can't really simply removed, but the sub queries and extra function 
> calls really doesn't make sense to be there when doing a count, so it seems 
> that all the options are quite bad and hackish.
>
> Any other options?
>
>
> El viernes, 24 de noviembre de 2017, 1:12:07 (UTC-3), Simon Charette 
> escribió:
>>
>> Hello Cristiano,
>>
>> > Isn't there a way (even if it's hackish) to simply clear the 
>> annotations (and order by)? I know querysets are smart enough to not 
>> include the order by clause if there's a count.
>>
>> The ordering is cleared on `count()` because it shouldn't interfere with 
>> the result in any way. You can clear annotations using 
>> `queryset.query.annotations.clear()` but be aware that it is a private API 
>> that could change under your feet. Make sure to make a copy of the queryset 
>> (e.g. copy = queryset.all()) before performing this change as it will alter 
>> the queryset in place.
>>
>> Best,
>> Simon
>>  
>> Le jeudi 23 novembre 2017 22:41:41 UTC-5, Cristiano Coelho a écrit :
>>>
>>> Hello Simon, thanks for the response.
>>>
>>> The above code is just an example, the reason behind the annotate 
>>> because there's some complicated code that builds a queryset and annotates 
>>> it so it can easily be reused. It works fine 99% of the time except when 
>>> there's a count involved and it ends up being redundant. The solution would 
>>> be to not annotate anything and replace the code in multiple places to add 
>>> the annotate call (or similar using a custom queryset or manager I guess), 
>>> but that's quite painful and will end up with a lot of duplicated code 
>>> since there's also an order_by that follows the annotate that needs to be 
>>> moved over as well
>>>
>>> Isn't there a way (even if it's hackish) to simply clear the annotations 
>>> (and order by)? I know querysets are smart enough to not include the order 
>>> by clause if there's a count.
>>>
>>> You could also suggest using two separate calls or a flag to pass down 
>>> to the internal code so it doesn't include the additional stuff, but that 
>>> wouldn't work since paginators accept only one query set for example and 
>>> internall uses it for both count and results.
>>>
>>>
>>>
>>> El viernes, 24 de noviembre de 2017, 0:05:29 (UTC-3), Simon Charette 
>>> escribió:

 Hello Cristiano,

 I understand your frustration but please avoid using the developer 
 mailing list
 as a second tier support channel. I suggest you try the IRC #django 
 channel if
 you need to want to get faster support.

 What's happening here is that annotate() really means "select this 
 field" while
 in your other case you use a lookup (summary__icontains) which are only 
 going to
 be added to the WHERE clause of your query.

 I'm not sure why you are annotating your queryset without referring to 
 it in
 a filter clause later on but the ORM cannot simply ignore it when you 
 are
 performing your `count()` because some annotations could interfere with 
 grouping
 somehow.

 There is an open ticket[0] to add support for an `alias()` method that 
 would
 allow the 

Re: Blue colored python file in Django Project structure.

[Unnati C]

Yup, This is pycharm IDE, and thanks for guidlines.

On Friday, November 24, 2017 at 10:53:40 PM UTC+5:30, Dylan Reinhold wrote:
>
> This has nothing to do with django or python. This is your IDE using 
> colors to give you status information. Looking like you are using pycharm. 
> By default (which you can change) blue just means the file has been updated.
> https://www.jetbrains.com/help/pycharm/file-status-highlights.html
>
> Dylan
>
> On Fri, Nov 24, 2017 at 9:14 AM, Unnati C  > wrote:
>
>> hello,
>>
>> While working on Django project, suddenly one of my python file name in 
>> structure changed to blue. Till now it does not raise any error, but I am 
>> shock why it happened. 
>> Is anybody have idea regarding this change in django project directory.. 
>>
>> -- 
>> 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/b92ae807-4561-4dd8-a372-f7b41a31bb11%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d19b00b1-48c7-4232-af4b-16fa3b1b9c0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Blue colored python file in Django Project structure.

[Dylan Reinhold]

This has nothing to do with django or python. This is your IDE using colors
to give you status information. Looking like you are using pycharm. By
default (which you can change) blue just means the file has been updated.
https://www.jetbrains.com/help/pycharm/file-status-highlights.html

Dylan

On Fri, Nov 24, 2017 at 9:14 AM, Unnati C  wrote:

> hello,
>
> While working on Django project, suddenly one of my python file name in
> structure changed to blue. Till now it does not raise any error, but I am
> shock why it happened.
> Is anybody have idea regarding this change in django project directory..
>
> --
> 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/b92ae807-4561-4dd8-a372-f7b41a31bb11%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHtg44CAnuyV-CVemQx5ihzwTZfLmH-Cc2g3GAWZ-P8AtKRGbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Blue colored python file in Django Project structure.

[Unnati C]

hello,

While working on Django project, suddenly one of my python file name in 
structure changed to blue. Till now it does not raise any error, but I am 
shock why it happened. 
Is anybody have idea regarding this change in django project directory.. 

-- 
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/b92ae807-4561-4dd8-a372-f7b41a31bb11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Development server inaccessible from the browser

[Dylan Reinhold]

Is your development server the same machine you are running your browser
from?

If not you don't want to use localhost, you need to user the IP/domain name
of the development server.

What is the error you get in the browser?

Dylan

On Fri, Nov 24, 2017 at 2:47 AM, Harish Oraon  wrote:

> This might be your settings, please confirm
>
> DEBUG=False
> ALLOWED_HOST = []
>
> Try these two
> a)
>DEBUG = True
>ALLOWED_HOST = []
> b)
>DEBUG = False
>ALLOWED_HOST = ['localhost', '127.0.0.1',]
>
> On Friday, 24 November 2017 15:42:22 UTC+5:30, ngn zone wrote:
>>
>> Hello all,
>>
>>   I have a very strange experience with my Development server.
>> 1. I ran python manage.py makemigrations and it was successful
>>
>> 2. I ran python manage.py migrate every ran successful to my postgresql db
>>
>> 3. I ran python manage.py runserver everything successfu with following
>> output attched to this post.
>>
>> 4. When I head over to my web browser and type localhost:8000
>>
>> 5. The browser shows this site can't be access.
>>
>> 6. when I run other projects on the same computer it runs just fine but
>> for the afore mentioned.
>>I am running my project on virtualenv.
>>
>> 7. I am using linux mint 17 django 1.11.2
>>
>> My Question is, what is wrong with my code that permits migrations and
>> the development server to run without errors but on the browser I cannot
>> access any url of my project?
>>
>> Desperately waiting for your help.
>>
> --
> 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/2bf18a17-5427-4b82-9c12-2ca86f9faf4c%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHtg44Acpa%2B%2BmXxST_9W1A8-RWY-sz5MaYaSQxxc4EN%3DB3-dHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Development server inaccessible from the browser

[Harish Oraon]

This might be your settings, please confirm

DEBUG=False
ALLOWED_HOST = []

Try these two
a)
   DEBUG = True
   ALLOWED_HOST = []
b)
   DEBUG = False
   ALLOWED_HOST = ['localhost', '127.0.0.1',]

On Friday, 24 November 2017 15:42:22 UTC+5:30, ngn zone wrote:
>
> Hello all, 
>
>   I have a very strange experience with my Development server. 
> 1. I ran python manage.py makemigrations and it was successful
>
> 2. I ran python manage.py migrate every ran successful to my postgresql db
>
> 3. I ran python manage.py runserver everything successfu with following 
> output attched to this post.
>
> 4. When I head over to my web browser and type localhost:8000
>
> 5. The browser shows this site can't be access.
>
> 6. when I run other projects on the same computer it runs just fine but 
> for the afore mentioned.
>I am running my project on virtualenv.
>
> 7. I am using linux mint 17 django 1.11.2
>
> My Question is, what is wrong with my code that permits migrations and the 
> development server to run without errors but on the browser I cannot access 
> any url of my project?
>
> Desperately waiting for your help.
>

-- 
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/2bf18a17-5427-4b82-9c12-2ca86f9faf4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Strange query when using annotate and count

[Cristiano Coelho]

Hello Simon,

That private API is good to know, but now that I think of it would still 
not work for me, since my queryset is passed to a paginator and that's the 
class that does both the count and actual queryset execution, so need a 
queryset that can have both the annotation but also clears it if count is 
called so it doesn't create the redundant sub queries.

I'm wondering what's better, should I try to resolve this at the manager 
level overriding count? I feel like this might cause issues if the 
annotation is actually legit (ie with an aggregate) and it needs the 
subquery after all.
The other option is to subclass the paginator class with a special one that 
does this annotation clearing before running count.

Even with these cases, if the annotated value is used later with a filter 
query I can't really simply removed, but the sub queries and extra function 
calls really doesn't make sense to be there when doing a count, so it seems 
that all the options are quite bad and hackish.

Any other options?


El viernes, 24 de noviembre de 2017, 1:12:07 (UTC-3), Simon Charette 
escribió:
>
> Hello Cristiano,
>
> > Isn't there a way (even if it's hackish) to simply clear the annotations 
> (and order by)? I know querysets are smart enough to not include the order 
> by clause if there's a count.
>
> The ordering is cleared on `count()` because it shouldn't interfere with 
> the result in any way. You can clear annotations using 
> `queryset.query.annotations.clear()` but be aware that it is a private API 
> that could change under your feet. Make sure to make a copy of the queryset 
> (e.g. copy = queryset.all()) before performing this change as it will alter 
> the queryset in place.
>
> Best,
> Simon
>  
> Le jeudi 23 novembre 2017 22:41:41 UTC-5, Cristiano Coelho a écrit :
>>
>> Hello Simon, thanks for the response.
>>
>> The above code is just an example, the reason behind the annotate because 
>> there's some complicated code that builds a queryset and annotates it so it 
>> can easily be reused. It works fine 99% of the time except when there's a 
>> count involved and it ends up being redundant. The solution would be to not 
>> annotate anything and replace the code in multiple places to add the 
>> annotate call (or similar using a custom queryset or manager I guess), but 
>> that's quite painful and will end up with a lot of duplicated code since 
>> there's also an order_by that follows the annotate that needs to be moved 
>> over as well
>>
>> Isn't there a way (even if it's hackish) to simply clear the annotations 
>> (and order by)? I know querysets are smart enough to not include the order 
>> by clause if there's a count.
>>
>> You could also suggest using two separate calls or a flag to pass down to 
>> the internal code so it doesn't include the additional stuff, but that 
>> wouldn't work since paginators accept only one query set for example and 
>> internall uses it for both count and results.
>>
>>
>>
>> El viernes, 24 de noviembre de 2017, 0:05:29 (UTC-3), Simon Charette 
>> escribió:
>>>
>>> Hello Cristiano,
>>>
>>> I understand your frustration but please avoid using the developer 
>>> mailing list
>>> as a second tier support channel. I suggest you try the IRC #django 
>>> channel if
>>> you need to want to get faster support.
>>>
>>> What's happening here is that annotate() really means "select this 
>>> field" while
>>> in your other case you use a lookup (summary__icontains) which are only 
>>> going to
>>> be added to the WHERE clause of your query.
>>>
>>> I'm not sure why you are annotating your queryset without referring to 
>>> it in
>>> a filter clause later on but the ORM cannot simply ignore it when you are
>>> performing your `count()` because some annotations could interfere with 
>>> grouping
>>> somehow.
>>>
>>> There is an open ticket[0] to add support for an `alias()` method that 
>>> would
>>> allow the ORM to clear/ignore the specified expressions if it's not 
>>> referenced
>>> in the query.
>>>
>>> In the mean time I think the best approach would be to avoid annotating 
>>> the
>>> queryset if your don't need to reference the score.
>>>
>>> Cheers,
>>> Simon
>>>
>>> [0] https://code.djangoproject.com/ticket/27719
>>>
>>> Le mardi 21 novembre 2017 08:46:21 UTC-5, Cristiano Coelho a écrit :

 Hmm, should I try with the dev mailing list? Guess it's something no 
 one faced before?

 El martes, 14 de noviembre de 2017, 22:54:23 (UTC-3), Cristiano Coelho 
 escribió:
>
> I'm getting some very odd query when combining annotate with count. 
> See the following:
>
> >>> q = 
>> Vulnerability.objects.annotate(score=WordTrigramCustomSimilarity('test','summary'))
>> >>> q.count()
>> 3094
>> >>> print connection.queries[-1]
>> 'SELECT COUNT(*) 
>> FROM (
>> SELECT "vulnerabilities_vulnerability"."id" AS Col1, 
>> custom_word_similarity(\'test\', 
>> 

Re: Django 2.0 tutorial

[Carl Brubaker]

I figured it out. I had a space in between the "path(' '," single quotes in 
the polls.urls and there isn't supposed to be one. Thanks for all of your 
help.

-- 
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/4759247b-88e6-458a-a19b-8a24c5798b7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.11 run error

[ngn]

Thanks Jason, That solved the problem.

I am grateful


On 11/23/2017 02:43 PM, Jason wrote:
If this is a new environment with existing source code, did you 
install all the requirements?  eg, is there a requirements.txt file in 
the project root, and did you execute pip install -r requirements.txt 
when the virtual env was activated?


If so, try running pip install python-dotenv

Your error message says it can't find that module, so I suspect the 
python-dotenv package hasn't been installed to your virtualenv

--
You received this message because you are subscribed to a topic in the 
Google Groups "Django users" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-users/wxSoCYhwDfg/unsubscribe.
To unsubscribe from this group and all its topics, 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/189476e6-22b6-4caa-9f74-beb24999c3c2%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0f3a9a43-db75-712f-59d8-6f6373fb7c9f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AttributeError: 'TemplateResponse' object has no attribute '_reason_phrase'

[Web Architect]

Figured out why the issue was occurring. I had written a cache decorator to 
cache based on per user:

def cache_per_user_method(ttl=None, prefix=None, cache_post=False):

'''

Decorator which caches the view for each User

* ttl - the cache lifetime, do not send this parameter means that the 
cache

  will last until the restart server or decide to remove it

* prefix - Prefix to use to store the response in the cache. If not 
informed,

  it will be used 'view_cache _' + function.__ name__

* cache_post - Determine whether to make requests cache POST

* The caching for anonymous users is shared with everyone


How to use it:

@cache_per_user_method(ttl=3600, cache_post=False)

def get(self, request):

...

'''

def decorator(view_method):

def apply_cache(obj, request, *args, **kwargs):


CACHE_KEY = cache_key(request, prefix)


logger.debug("cache key %s",CACHE_KEY)


# Verifica se pode fazer o cache do request

if not cache_post and request.method == 'POST':

can_cache = False

else:

can_cache = True


if can_cache:

response = core_cache.get(CACHE_KEY, None)

else:

response = None


if not response:

response = view_method(obj, request, *args, **kwargs)

logger.debug("cache not found in decorator")

if can_cache and hasattr(response, 'render'):

logger.debug("cache set in decorator")

core_cache.set(CACHE_KEY, response.render(), ttl)

return response

return apply_cache


The above code was causing the error to happen but couldn't figure out 
where the issue was in the above. 


Thanks,

On Wednesday, November 22, 2017 at 9:44:59 PM UTC+5:30, Tim Graham wrote:
>
> I tried a Google search for the last line of the error message and came to 
> https://code.djangoproject.com/ticket/25964. Conclusion: try clearing 
> your cache.
>
> On Wednesday, November 22, 2017 at 3:29:42 AM UTC-5, Web Architect wrote:
>>
>> Hi,
>>
>> We recently migrated from Django 1.8 to Django 1.11.7. We have an 
>> ecommerece site running on Django. When we are trying to access a page, 
>> following exception is occuring:
>>
>> Traceback (most recent call last):
>>
>>   File "/usr/local/lib/python2.7/wsgiref/handlers.py", line 85, in run
>>
>> self.result = application(self.environ, self.start_response)
>>
>>   File 
>> "/virenv/lib/python2.7/site-packages/django/contrib/staticfiles/handlers.py",
>>  
>> line 63, in __call__
>>
>> return self.application(environ, start_response)
>>
>>   File 
>> "/virenv/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 
>> 161, in __call__
>>
>> status = '%d %s' % (response.status_code, response.reason_phrase)
>>
>>   File "/virenv/lib/python2.7/site-packages/django/http/response.py", 
>> line 69, in reason_phrase
>>
>> if self._reason_phrase is not None:
>>
>> AttributeError: 'TemplateResponse' object has no attribute 
>> '_reason_phrase'
>>
>>
>> I am completely clueless why the above exception is occurring. I do not 
>> have any other data or logs for the above exception
>>
>>
>> Could anyone help me in providing a way to debug the above?
>>
>>
>> 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/27d1281c-2d9f-44f3-a6a3-d2e6672310c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.