date:20170403

Re: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Todor Velichkov

The first one will use a single JOIN on the entry table, and will apply 
both filters to that table.
The second one will JOIN the entry table twice, and for every join will 
apply only a single filter

On Sunday, April 2, 2017 at 5:41:29 PM UTC+3, Mahendra Gaur wrote:
>
> Hello everyone,
>
> I am newbie to django. Now-a-days am reading django docs.
> While reading models i got confusion that, What is the difference between 
> filter chaining and filter with multiple arguments.
> For example what is the diffrence between below two:
>
> Blog.objects.filter(entry__headline__contains='Lennon', 
> entry__pub_date__year=2008)
>
> Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)
>
>
> can some one please help me to understand how these both works and most 
> importantly what will be corresponding MYSQL queries for above two 
> statements ?
>
>
>
> Thanks and Regards,
> Mahendra
>
>

-- 
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/19f4e103-0325-4f8e-bd03-502a1f2fe002%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Login/Logout, single instance only

2017-04-03 Thread miguel vfx

Good day! I was wondering if there's a way to limit a user account to be 
logged-in in just 1 single device? I mean is there a way to logout a user 
first (In all browsers), then login? Thank you.

-- 
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/60fe0b1e-648b-4d8f-ab80-ffdfe8a518f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Login/Logout, single instance only

2017-04-03 Thread Avraham Serour

You could probably have a custom session management to only have one
session per user, when a user log in you can invalidate all the other user
sessions

On Mon, Apr 3, 2017 at 11:30 AM, miguel vfx  wrote:

> Good day! I was wondering if there's a way to limit a user account to be
> logged-in in just 1 single device? I mean is there a way to logout a user
> first (In all browsers), then login? Thank you.
>
> --
> 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/60fe0b1e-648b-4d8f-ab80-ffdfe8a518f5%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/CAFWa6tJQUFCJSyZJMGyciXpECZmO-6fYkuUCR2ir91Q0WFL1mA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

BDD in Django

2017-04-03 Thread Renato César Lira Borges

Hello everyone, I have a simple question:

*What better library to BDD in Django? And why?*

-- 
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/9a158a22-f0c3-4e0b-b0e0-0faefafc5e33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cannot install channels

2017-04-03 Thread David W

I would add that the required package could be "python3.6-dev" if you're 
working with Python 3.6.

On Friday, February 10, 2017 at 8:16:17 AM UTC+1, Robin Lery wrote:
>
> Yes. That might have been the problem. Thank you once again!
>
> On Fri, Feb 10, 2017 at 12:43 PM, Andrew Godwin  > wrote:
>
>> I'm afraid I can't help without looking at the machine directly - I would 
>> suspect that either it had a version of Twisted pre-installed on the system 
>> that it was happy with (the more recent releases increased the Twisted 
>> version requirement), or the version of Twisted it downloaded did not 
>> require compilation.
>>
>> Andrew
>>
>> On Thu, Feb 9, 2017 at 11:10 PM, Robin Lery > > wrote:
>>
>>> Yes that was it. Thank you. Could you please help me understand why this 
>>> might have worked before in a earlier different virtual env in the same 
>>> vagrant machine?
>>>
>>> On Fri, Feb 10, 2017 at 12:28 PM, Andrew Godwin >> > wrote:
>>>
 You don't have the Python development headers installed for your system 
 - you can tell this because of this line in the error:

 src/twisted/test/raiser.c:4:20: fatal error: Python.h: No such file or 
 directory

 If you install your distribution's python header package (e.g. on 
 ubuntu it's python-dev) it should resolve the error.

 Andrew

 On Thu, Feb 9, 2017 at 10:51 PM, Robin Lery >>> > wrote:

> Hi,
>
> I already had a django channels in my other virtual env. But since its 
> an older version of channels (0.7.0) I am trying to install a new channel 
> version into my project which is in a different virtual environment 
> inside 
> a a vagrant box.
>
> I created a new virtualenv
>
>> $ mkvirtualenv newsapp
>>
>
> Install django
>
>> $ pip install django
>>
>
> Install channels
>
>> $ pip install -U channels
>>
>
> Then I am getting error:
>
> Command "/home/vagrant/Envs/newsapp/bin/python -u -c "import 
>> setuptools, 
>> tokenize;__file__='/tmp/pip-build-IrzQ_E/twisted/setup.py';f=getattr(tokenize,
>>  
>> 'open', open)(__file__);code=f.read().replace('\r\n', 
>> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
>> /tmp/pip-ArjPse-record/install-record.txt 
>> --single-version-externally-managed --compile --install-headers 
>> /home/vagrant/Envs/newsapp/include/site/python2.7/twisted" failed with 
>> error code 1 in /tmp/pip-build-IrzQ_E/twisted/
>
>
> Here is link for the full error
> 
> Can you please help how to solve 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...@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/CA%2B4-nGpCy3g5KD9Q-UctFF3oKuVqtdfTjkW6XuTLBPiH%2BpyTsw%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 https://groups.google.com/group/django-users.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-users/CAFwN1urVA5dAAKX2M06Ftny8BE8e9uVWTXKr6LFs-5xVim6j-Q%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 https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/CA%2B4-nGpddiY2fxD7papAQEP42f%2B43ZYOuCpXj7fjx_jCpzABXQ%40mail.gmail.com
>>>  
>>>

Re: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Mahendra Gaur

Thank you for reply.

In case of second statement, why two JOIN are required each with single
filter ?
As per my understanding whether it use one JOIN with both the filter or two
JOIN each with single filter, both are same.
correct me if am wrong ?



Thanks and Regards,
Mahendra

On Mon, Apr 3, 2017 at 1:39 PM, Todor Velichkov 
wrote:

> The first one will use a single JOIN on the entry table, and will apply
> both filters to that table.
> The second one will JOIN the entry table twice, and for every join will
> apply only a single filter
>
>
> On Sunday, April 2, 2017 at 5:41:29 PM UTC+3, Mahendra Gaur wrote:
>>
>> Hello everyone,
>>
>> I am newbie to django. Now-a-days am reading django docs.
>> While reading models i got confusion that, What is the difference between
>> filter chaining and filter with multiple arguments.
>> For example what is the diffrence between below two:
>>
>> Blog.objects.filter(entry__headline__contains='Lennon', 
>> entry__pub_date__year=2008)
>>
>> Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)
>>
>>
>> can some one please help me to understand how these both works and most
>> importantly what will be corresponding MYSQL queries for above two
>> statements ?
>>
>>
>>
>> Thanks and Regards,
>> Mahendra
>>
>> --
> 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/19f4e103-0325-4f8e-bd03-502a1f2fe002%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/CAExdeFbNanEPwgXCLuyuAMiA1XWPNVWGqvk%2BSnE8KxU67ExiZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer


On 02/04/2017 04:37, Some Developer wrote:

Hi,

I was wondering if function based views will ever be deprecated? I
absolutely hate class based views with a passion for various reasons
(too complex, trying to solve a problem that doesn't exist etc). With a
function based view I can write it in 2 minutes pretty much and handling
multiple forms on the same page is a piece of cake. The same is not true
of class based views. You need to look up which classes a certain class
based view inherits from to see what methods are available, handling
multiple forms on the same page is a pain in the arse if not impossible
and various other things that are just way more difficult than they
should be.

So yeah. Are function based views ever going to go away? I've already
noticed that in Django 1.11 the login() and logout() functions are going
away in favour of class based views which seems silly as I'll have to
rewrite my perfectly working user app to use class based views now.

Is that a sign of things to come? If that is what the developers are
planning can I please beg them to reconsider? Function based views are
just fine. You might prefer class based views but there are users out
there who much prefer function based views.

Please don't take this as an aggressive post. I love working with Django
and I'm just passioniate about it. This isn't a flame post.

Thank you for any help :).

Some Developer.


Hi,

I've just re-read my message and notice that it is extremely aggressive. 
I want to apologies for that. When I typed it I had just had a big 
argument with someone and it came across in my message to this list. 
That was uncalled for and I'm not normally that type of person. So sorry 
again.


If I post again I'll make sure to only do it when I am nice and happy :).

Some Developer.

--
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/6889bd08-29e6-e963-12ac-456441dd9c5f%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer


Hi,

Thank you for the link. I'll check it out.

On 02/04/2017 07:43, Antonis Christofides wrote:

Hi,

This is not an answer to your question (which was answered by James
Bennett anyway), but I liked this recent article about class vs.
function based views:

https://simpleisbetterthancomplex.com/article/2017/03/21/class-based-views-vs-function-based-views.html

This is his conclusion:

I usually always start my views as function-based views. If I can
use a generic class-based view just by overriding the attributes, I
go for it. If I have some very specific needs, and it will replicate
across several views, I create my own custom generic view
subclassing the |django.views.generic.View|.

Regards,

A.

Antonis Christofides
http://djangodeployment.com

On 04/02/2017 06:37 AM, Some Developer wrote:

Hi,

I was wondering if function based views will ever be deprecated? I
absolutely hate class based views with a passion for various reasons
(too complex, trying to solve a problem that doesn't exist etc). With
a function based view I can write it in 2 minutes pretty much and
handling multiple forms on the same page is a piece of cake. The same
is not true of class based views. You need to look up which classes a
certain class based view inherits from to see what methods are
available, handling multiple forms on the same page is a pain in the
arse if not impossible and various other things that are just way more
difficult than they should be.

So yeah. Are function based views ever going to go away? I've already
noticed that in Django 1.11 the login() and logout() functions are
going away in favour of class based views which seems silly as I'll
have to rewrite my perfectly working user app to use class based views
now.

Is that a sign of things to come? If that is what the developers are
planning can I please beg them to reconsider? Function based views are
just fine. You might prefer class based views but there are users out
there who much prefer function based views.

Please don't take this as an aggressive post. I love working with
Django and I'm just passioniate about it. This isn't a flame post.

Thank you for any help :).

Some Developer.



--
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/b65adf12-e46e-8baf-398b-edae0c0fbc85%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer


Hi,

Awesome thanks. I can see the reason for some class based views as they 
remove the need for boilerplate code but if you run into a problem with 
them for whatever reason you generally have to dig out the Python 
debugger and set a break point in your view to see what the Django 
framework code is doing in the background.


I can write just about any view I want in less than 5 minutes with a 
function based view. The only slow down on my end is my typing speed. I 
just find them much easier to understand and debug when you can look at 
the entire code for the view with nothing else getting in the way.


I think I will try again to use some class based views in my code just 
so I can make a more informed decision. I just remember my last attempt 
to use the FormView class based view with multiple forms on the same 
page and giving up in disgust because it was so much harder than doing 
the same thing in a function based view.


Some Developer.

On 02/04/2017 06:37, James Bennett wrote:

If you're asking "Will there ever be a point when all built-in views in
Django are class-based", the answer is "maybe", because whether to write
one of those class-based or function-based depends on what the view
needs to do, how much configurability/extensibility it needs to support,
etc.

If you're asking "Will there ever be a point when Django no longer
supports using functions as views, period", the answer is almost
certainly "no".

Officially, the definition of a Django view is a Python callable which
takes an HttpRequest object as its first positional argument, and which
either returns an HttpResponse object or raises an exception. That
definition is unlikely to change.




--
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/e8af988b-3fd2-f781-e33b-00fa9b2b205f%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

The Django server side shows http 400 and Invalid HTTP_HOST header message

2017-04-03 Thread Philip Lee



I am using HTTPHandler to send logging messages to a Django Web server with The 
following code, 

>
> import logging
> import logging.handlers
> logger = logging.getLogger('mylogger')
> http_handler = logging.handlers.HTTPHandler('localhost:8000', 
> '/VideoParser/lYYDownloaderClientLog')#, method='POST'
> logger.addHandler(http_handler)
> logger.error('testing remote logging')


but The server side shows http 400 and Invalid HTTP_HOST header message like 
this 

>
> Invalid HTTP_HOST header: 'localhost:8000,localhost'. The domain name 
> provided i
> s not valid according to RFC 1034/1035.
> [03/Apr/2017 19:15:41] "GET 
> /VideoParser/lYYDownloaderClientLog?filename=a.py&th
> readName=MainThread&stack_info=None&processName=MainProcess&exc_text=None&create
> d=1491218139.538086&levelname=ERROR&module=a&thread=3624&exc_info=None&relativeC
> reated=112.00642585754395&levelno=40&pathname=C%3A%5CUsers%5Ci%5CDocuments%5CTen
> cent+Files%5C2281570025%5CFileRecv%5Ca.py&msecs=538.0859375&msg=testing+remote+l
> ogging&name=mylogger&args=%28%29&lineno=12&process=6700&funcName=%3Cmodule%3E 
> HT
> TP/1.1" 400 67823


so how to fix The issue ?

related code
django-test\LYYDownloaderServer\VideoParser\urls.py

>
> from django.conf.urls import url
> from . import views
> app_name = 'VideoParser'
> urlpatterns = [
> url(r'lYYDownloaderClientLog.+',views.lYYDownloaderClientLog, 
> name='lYYDownloaderClientLog')
> ]


django-test\LYYDownloaderServer\VideoParser\views.py

>
> def lYYDownloaderClientLog(request):
> print('---', request.GET)

-- 
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/aa561085-f498-412e-9f2f-2e5af04df9a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Matthew Pava

Hi Mahendra,
You can view the SQL that is generated by using the query attribute on the 
QuerySet.

q = Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)

print(str(q.query))

That should help in understanding what is going on.
Best wishes!

From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Mahendra Gaur
Sent: Sunday, April 2, 2017 9:39 AM
To: django-users@googlegroups.com
Subject: filter chaining v/s filter with multiple arguments.

Hello everyone,

I am newbie to django. Now-a-days am reading django docs.
While reading models i got confusion that, What is the difference between 
filter chaining and filter with multiple arguments.
For example what is the diffrence between below two:


Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)

Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)

can some one please help me to understand how these both works and most 
importantly what will be corresponding MYSQL queries for above two statements ?



Thanks and Regards,
Mahendra

--
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/CAExdeFaPbedyCOuO_PHsRO3GcVC_nAMxNm6JCHfsJ%2BCn6bdssg%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 
https://groups.google.com/d/msgid/django-users/008b9ec564814285939b4b3cc406bb14%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

RE: How to design High Scalability architecture with Django in cost effective fashion

2017-04-03 Thread Matthew Pava

Hi Mihir,
Though I am no expert on distributed systems, you may want to check out the 
possible DATABASES settings.  You can specify multiple databases in your 
settings file.
See https://docs.djangoproject.com/en/1.10/topics/db/multi-db/
I would read about Django database routing to get started.  I believe there is 
a Django package out there that handles routing in a more convenient manner 
than out of the box; it is mentioned somewhere in this mailing list, but I 
can’t remember the name of it offhand.
Best wishes!

From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Mihir Sevak
Sent: Sunday, April 2, 2017 12:28 PM
To: Django users
Subject: How to design High Scalability architecture with Django in cost 
effective fashion

Hi All,
  I am wondering if there are any books, articles or any other resources 
from where I can learn about how to create a highly scalable architecture using 
Django. We are talking about distributed systems and most likely one which is 
hosted on a third party cloud solution like AWS. That being the case cost 
effectiveness is a concern as well.
Several years ago I used to work with LexisNexis on their super computer with 
6400 nodes. We had designed the system in a way that depending on load, nodes 
will be turned on and off automatically saving us bandwidth usage and 
electricity/power usage. I am envisioning similar architecture using Django. 
However, I have no clue how to put multiple database back end with same django 
frontend or what does middleware do or if we have 15 different django 
applications running to create a whole functional website how to distribute 
those 15 applications among nodes etc etc.
I am really a newbee in django architecture and because I don't know enough 
about django I don't know how to leverage distributed architecture and make 
django work with it.
If anyone can share any education material about how Django is architectured in 
order to build distributed systems effectively and reliably that would be 
absolutely wonderful. If there are any open source projects which I can take a 
look at and learn that would be great as well.

Thanks.
Have a great day and wonderful weekend.
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
--
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/45e97ff1-4e6f-4bd8-a0b9-b62d6f42d533%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/ad919a692b15411793193bcf3de7b537%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

Filter list dict in JsonField Postgres

2017-04-03 Thread Martin Peveri

Hi, I have this model:

class ItemCampaign(models.Model):

   campaign = models.ForeignKey(
   Campaign, related_name="itemscampaign", verbose_name="Item campaña"
   )
   data = JSONField(default=dict)

   def __str__(self):
   return self.campaign.name 

With a record with this data: 

[{'number': '1160188479', 'id': 0, 'content': 'hello', 'processed': True}, {
'number': '1160188479', 'id': 1, 'content': 'hello', 'processed': False}, {
'number': '1160188479', 'id': 2,'content': 'hello', 'processed': False}, {
'number': '1162341721', 'id': 3, 'content': 'hello', 'processed': False}, {
'number': '1162341721', 'id': 4, 'content': 'hello', 'processed':False}, {
'number': '1162341721', 'id': 5, 'content': 'hello', 'processed': False}]

I want filter this list dict, like this:

c.itemscampaign.filter(data__processed=True)

But not work. That does not give me back anything.

The content type of data is:

>>> type(c.itemscampaign.all()[0].data)


I understand that it has to be a dict, but how can I insert many 
dictionaries in the field, as I have in my data if it is not in a list?

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/27feeb2b-6b41-4d3a-b771-08653a99d9c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Mahendra Gaur

Thanks for reply.

I have tried q.query on both statements but both are giving same query. I
had tried this even before initiating this mail chain, and this was the
point where I got confused.

Thanks and regards,
Mahendra Gaur

On 3 Apr 2017 6:55 p.m., "Matthew Pava" wrote:

Hi Mahendra,

You can view the SQL that is generated by using the query attribute on the
QuerySet.

q = Blog.objects.filter(entry__headline__contains='Lennon',
entry__pub_date__year=2008)

print(str(q.query))

That should help in understanding what is going on.

Best wishes!

*From:* django-users@googlegroups.com [mailto:django-users@googlegroups.com]
*On Behalf Of *Mahendra Gaur
*Sent:* Sunday, April 2, 2017 9:39 AM
*To:* django-users@googlegroups.com
*Subject:* filter chaining v/s filter with multiple arguments.

Hello everyone,

I am newbie to django. Now-a-days am reading django docs.

While reading models i got confusion that, What is the difference between
filter chaining and filter with multiple arguments.

For example what is the diffrence between below two:

Blog.objects.filter(entry__headline__contains='Lennon',
entry__pub_date__year=2008)

Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)

can some one please help me to understand how these both works and most
importantly what will be corresponding MYSQL queries for above two
statements ?

Thanks and Regards,

Mahendra

--
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/CAExdeFaPbedyCOuO_PHsRO3GcVC_nAMxNm6JCHfsJ%2BCn6bdssg%
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
https://groups.google.com/d/msgid/django-users/CAExdeFb7Zs0vrMKT5m%3DtkPJB1rRboq%2B5FsTKZ9V6%3DqVkWTGZag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Andréas Kühne

I find it interesting that so many haven't embraced the new CBV's. I ONLY
use CBV's when designing and find the usages much simpler - because of no
boilerplate and also the fact that I can derive from other classes when
needed.

Of course - the first time you use a form view or a template view and you
find yourself having problems - debugging that could take a while, however,
once you have done that I really haven't seen this as an issue. Also
because most of the default views inherit from the same mixins - once you
have understood how one works - you usually get the hang of it.

It could be that the first thing I did in django was to refactor views from
function based to class based - and therefore haven't started exploring
FBV's more :-)

Just my 2 cents...

Regards,

Andréas

2017-04-03 13:52 GMT+02:00 Some Developer :

> Hi,
>
> Awesome thanks. I can see the reason for some class based views as they
> remove the need for boilerplate code but if you run into a problem with
> them for whatever reason you generally have to dig out the Python debugger
> and set a break point in your view to see what the Django framework code is
> doing in the background.
>
> I can write just about any view I want in less than 5 minutes with a
> function based view. The only slow down on my end is my typing speed. I
> just find them much easier to understand and debug when you can look at the
> entire code for the view with nothing else getting in the way.
>
> I think I will try again to use some class based views in my code just so
> I can make a more informed decision. I just remember my last attempt to use
> the FormView class based view with multiple forms on the same page and
> giving up in disgust because it was so much harder than doing the same
> thing in a function based view.
>
> Some Developer.
>
> On 02/04/2017 06:37, James Bennett wrote:
>
>> If you're asking "Will there ever be a point when all built-in views in
>> Django are class-based", the answer is "maybe", because whether to write
>> one of those class-based or function-based depends on what the view
>> needs to do, how much configurability/extensibility it needs to support,
>> etc.
>>
>> If you're asking "Will there ever be a point when Django no longer
>> supports using functions as views, period", the answer is almost
>> certainly "no".
>>
>> Officially, the definition of a Django view is a Python callable which
>> takes an HttpRequest object as its first positional argument, and which
>> either returns an HttpResponse object or raises an exception. That
>> definition is unlikely to change.
>>
>>
>
> --
> 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/ms
> gid/django-users/e8af988b-3fd2-f781-e33b-00fa9b2b205f%40googlemail.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/CAK4qSCcvw_YUFfKm%2BtcsByByBZbcReuB1VG6%2BNFiquJO2MamsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer

Try doing something that a class based view doesn't support out of the 
box and then you'll understand why function based views are still used. 
Even something as simple as returning some JSON means you have to dig 
into how a class based view works where as it is about 3 lines of code 
in a function based view.


Then what about a view that has to handle 2 (or more) different form 
classes on the same page? You'll soon find that having to do that in a 
class based view means major work rewriting or building your own class 
based view.


As I said I'll give them another go but I've yet to be convinced of 
their greatness.


On 03/04/2017 15:54, Andréas Kühne wrote:

I find it interesting that so many haven't embraced the new CBV's. I
ONLY use CBV's when designing and find the usages much simpler - because
of no boilerplate and also the fact that I can derive from other classes
when needed.

Of course - the first time you use a form view or a template view and
you find yourself having problems - debugging that could take a while,
however, once you have done that I really haven't seen this as an issue.
Also because most of the default views inherit from the same mixins -
once you have understood how one works - you usually get the hang of it.

It could be that the first thing I did in django was to refactor views
from function based to class based - and therefore haven't started
exploring FBV's more :-)

Just my 2 cents...

Regards,

Andréas

2017-04-03 13:52 GMT+02:00 Some Developer mailto:someukdevelo...@gmail.com>>:

Hi,

Awesome thanks. I can see the reason for some class based views as
they remove the need for boilerplate code but if you run into a
problem with them for whatever reason you generally have to dig out
the Python debugger and set a break point in your view to see what
the Django framework code is doing in the background.

I can write just about any view I want in less than 5 minutes with a
function based view. The only slow down on my end is my typing
speed. I just find them much easier to understand and debug when you
can look at the entire code for the view with nothing else getting
in the way.

I think I will try again to use some class based views in my code
just so I can make a more informed decision. I just remember my last
attempt to use the FormView class based view with multiple forms on
the same page and giving up in disgust because it was so much harder
than doing the same thing in a function based view.

Some Developer.

On 02/04/2017 06:37, James Bennett wrote:

If you're asking "Will there ever be a point when all built-in
views in
Django are class-based", the answer is "maybe", because whether
to write
one of those class-based or function-based depends on what the view
needs to do, how much configurability/extensibility it needs to
support,
etc.

If you're asking "Will there ever be a point when Django no longer
supports using functions as views, period", the answer is almost
certainly "no".

Officially, the definition of a Django view is a Python callable
which
takes an HttpRequest object as its first positional argument,
and which
either returns an HttpResponse object or raises an exception. That
definition is unlikely to change.



--
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/7d612ef6-4438-70ab-9aea-d5595af22e5a%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Vijay Khemlani

Any function based view can be reduced to a CBV trivially

class MyView(View):
   def get(request):# or post, or whatever http method
  

Point is there are patterns that repeat themselves enough to justify CBV,
aside from the benefits of using classes (inheritance, mixins, etc).

Also

"I can write just about any view I want in less than 5 minutes with a
function based view. The only slow down on my end is my typing speed."

If your typing speed is the limiting factor in your workflow... *shudders*

On Mon, Apr 3, 2017 at 12:01 PM, Some Developer 
wrote:

> Try doing something that a class based view doesn't support out of the box
> and then you'll understand why function based views are still used. Even
> something as simple as returning some JSON means you have to dig into how a
> class based view works where as it is about 3 lines of code in a function
> based view.
>
> Then what about a view that has to handle 2 (or more) different form
> classes on the same page? You'll soon find that having to do that in a
> class based view means major work rewriting or building your own class
> based view.
>
> As I said I'll give them another go but I've yet to be convinced of their
> greatness.
>
> On 03/04/2017 15:54, Andréas Kühne wrote:
>
>> I find it interesting that so many haven't embraced the new CBV's. I
>> ONLY use CBV's when designing and find the usages much simpler - because
>> of no boilerplate and also the fact that I can derive from other classes
>> when needed.
>>
>> Of course - the first time you use a form view or a template view and
>> you find yourself having problems - debugging that could take a while,
>> however, once you have done that I really haven't seen this as an issue.
>> Also because most of the default views inherit from the same mixins -
>> once you have understood how one works - you usually get the hang of it.
>>
>> It could be that the first thing I did in django was to refactor views
>> from function based to class based - and therefore haven't started
>> exploring FBV's more :-)
>>
>> Just my 2 cents...
>>
>> Regards,
>>
>> Andréas
>>
>> 2017-04-03 13:52 GMT+02:00 Some Developer > >:
>>
>>
>> Hi,
>>
>> Awesome thanks. I can see the reason for some class based views as
>> they remove the need for boilerplate code but if you run into a
>> problem with them for whatever reason you generally have to dig out
>> the Python debugger and set a break point in your view to see what
>> the Django framework code is doing in the background.
>>
>> I can write just about any view I want in less than 5 minutes with a
>> function based view. The only slow down on my end is my typing
>> speed. I just find them much easier to understand and debug when you
>> can look at the entire code for the view with nothing else getting
>> in the way.
>>
>> I think I will try again to use some class based views in my code
>> just so I can make a more informed decision. I just remember my last
>> attempt to use the FormView class based view with multiple forms on
>> the same page and giving up in disgust because it was so much harder
>> than doing the same thing in a function based view.
>>
>> Some Developer.
>>
>> On 02/04/2017 06:37, James Bennett wrote:
>>
>> If you're asking "Will there ever be a point when all built-in
>> views in
>> Django are class-based", the answer is "maybe", because whether
>> to write
>> one of those class-based or function-based depends on what the
>> view
>> needs to do, how much configurability/extensibility it needs to
>> support,
>> etc.
>>
>> If you're asking "Will there ever be a point when Django no longer
>> supports using functions as views, period", the answer is almost
>> certainly "no".
>>
>> Officially, the definition of a Django view is a Python callable
>> which
>> takes an HttpRequest object as its first positional argument,
>> and which
>> either returns an HttpResponse object or raises an exception. That
>> definition is unlikely to change.
>>
>
>
> --
> 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/ms
> gid/django-users/7d612ef6-4438-70ab-9aea-d5595af22e5a%40googlemail.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

Re: How to design High Scalability architecture with Django in cost effective fashion

2017-04-03 Thread Nate Granatir

I am also not even close to being an expert on this topic, but I do know 
that it's super easy to deploy a Django app on Heroku, which will get you 
scalable app deployment and Postgres dbs with very little upfront effort.
https://devcenter.heroku.com/articles/deploying-python

Nate

On Sunday, April 2, 2017 at 1:54:46 PM UTC-5, Mihir Sevak wrote:
>
> Hi All,
>   I am wondering if there are any books, articles or any other 
> resources from where I can learn about how to create a highly scalable 
> architecture using Django. We are talking about distributed systems and 
> most likely one which is hosted on a third party cloud solution like AWS. 
> That being the case cost effectiveness is a concern as well. 
>
> Several years ago I used to work with LexisNexis on their super computer 
> with 6400 nodes. We had designed the system in a way that depending on 
> load, nodes will be turned on and off automatically saving us bandwidth 
> usage and electricity/power usage. I am envisioning similar architecture 
> using Django. However, I have no clue how to put multiple database back end 
> with same django frontend or what does middleware do or if we have 15 
> different django applications running to create a whole functional website 
> how to distribute those 15 applications among nodes etc etc. 
>
> I am really a newbee in django architecture and because I don't know 
> enough about django I don't know how to leverage distributed architecture 
> and make django work with it. 
>
> If anyone can share any education material about how Django is 
> architectured in order to build distributed systems effectively and 
> reliably that would be absolutely wonderful. If there are any open source 
> projects which I can take a look at and learn that would be great as well.  
>
>
> Thanks.
> Have a great day and wonderful weekend.
>

-- 
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/18007f34-2ecb-4736-a05a-7e857f437571%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Matthew Pava

Hi Mahendra,
Then that would suggest that there really is no difference for the purposes of 
generating the SQL statement in chaining filters as opposed to adding multiple 
arguments in one filter, wouldn’t it?

So you might then wonder why do any chaining?  Well, sometimes we assign a 
filter to a variable and then we want to add further filters based on some 
condition in the code.  We can simply chain the filter in that situation rather 
than create a dict of arguments to the filter.  I suppose it is a matter of 
style and preference.  Since QuerySets are evaluated lazily, there is no 
performance degradation with either option.  I personally prefer chaining the 
filters together.


q = Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)

if select_only_january:

 q = q.filter(entry__pub_date__month=0)

--or create a keyword dictionary--


kwargs = { 'entry__headline__contains': 'Lennon', 'entry__pub_date__year': 2008 
}

if select_only_january:

 kwargs['entry__pub_date__month'] =0

q = Blog.objects.filter(**kwargs)
There are other ways of doing it to with Q objects.
I hope this helps.


From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Mahendra Gaur
Sent: Monday, April 3, 2017 9:42 AM
To: django-users@googlegroups.com
Subject: RE: filter chaining v/s filter with multiple arguments.

Thanks for reply.

I have tried q.query on both statements but both are giving same query. I had 
tried this even before initiating this mail chain, and this was the point where 
I got confused.



Thanks and regards,
Mahendra Gaur


On 3 Apr 2017 6:55 p.m., "Matthew Pava" 
mailto:matthew.p...@iss.com>> wrote:
Hi Mahendra,
You can view the SQL that is generated by using the query attribute on the 
QuerySet.

q = Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)

print(str(q.query))

That should help in understanding what is going on.
Best wishes!

From: django-users@googlegroups.com 
[mailto:django-users@googlegroups.com] On 
Behalf Of Mahendra Gaur
Sent: Sunday, April 2, 2017 9:39 AM
To: django-users@googlegroups.com
Subject: filter chaining v/s filter with multiple arguments.

Hello everyone,

I am newbie to django. Now-a-days am reading django docs.
While reading models i got confusion that, What is the difference between 
filter chaining and filter with multiple arguments.
For example what is the diffrence between below two:


Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)

Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)

can some one please help me to understand how these both works and most 
importantly what will be corresponding MYSQL queries for above two statements ?



Thanks and Regards,
Mahendra

--
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/CAExdeFaPbedyCOuO_PHsRO3GcVC_nAMxNm6JCHfsJ%2BCn6bdssg%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 
https://groups.google.com/d/msgid/django-users/008b9ec564814285939b4b3cc406bb14%40ISS1.ISS.LOCAL.

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/

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer

Most views are incredibly simple. Query database, maybe do a security 
check on the logged in user if the data shouldn't be public or only some 
users / groups can view it (yeah one thing I don't use as often as I 
should but will be using more of in the future is the built in Django 
permissions system), return data and add it to template context. Done.


Forms might add a couple of minutes per form. Just need to check that 
each form is valid and save the results or do the database search as 
required. Neither requires much programming time or skill.


I don't see why any of that should take any more than 5 minutes. Before 
I started programming in Python / Django I was a C programmer. Now that 
takes time because there are so many mistakes you can make in C unless 
you are on the ball. In comparison Python and Django is a piece of cake.


The thing that takes the time is planning out features and making sure 
your unit tests are comprehensive. Also making sure your models are well 
designed. I can easily spend 2 times the amount of time planning out 
features than I do actually programming and my philosophy when it comes 
to programming is have the absolute bear minimum of code in your views. 
If you can get rid of code then do so.


On 03/04/2017 16:10, Vijay Khemlani wrote:


Also

"I can write just about any view I want in less than 5 minutes with a
function based view. The only slow down on my end is my typing speed."

If your typing speed is the limiting factor in your workflow... *shudders*




--
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/30a5eab2-dee9-eaff-66e4-105ba85bf0bf%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: filter chaining v/s filter with multiple arguments.

2017-04-03 Thread Todor Velichkov

Nope, they are not the same.

The first one:

Blog.objects.filter(entry__headline__contains='Lennon', 
entry__pub_date__year=2008)


Will produce the following SQL:
SELECT 
"blog_blog"."id",
"blog_blog"."name",
"blog_blog"."tagline"
FROM 
"blog_blog" 
INNER JOIN "blog_entry" ON ("blog_blog"."id" = "blog_entry"."blog_id") 
WHERE (
"blog_entry"."pub_date" BETWEEN 2008-01-01 AND 2008-12-31 
AND "blog_entry"."headline" LIKE %Lennon% ESCAPE '\'
)

Which can be translated as:

> select all blogs that contain entries with both *“Lennon”* in the 
> headline and that were published in 2008 (the same entry satisfying both 
> conditions)
>

 
While the second one:
Blog.objects.filter(entry__headline__contains='Lennon').filter(
entry__pub_date__year=2008)

Will produce:
SELECT 
"blog_blog"."id",
"blog_blog"."name",
"blog_blog"."tagline"
FROM "blog_blog" 
INNER JOIN "blog_entry" ON ("blog_blog"."id" = "blog_entry"."blog_id")
INNER JOIN "blog_entry" T3 ON ("blog_blog"."id" = T3."blog_id") 
WHERE (
T3."pub_date" BETWEEN 2008-01-01 AND 2008-12-31
ABD "blog_entry"."headline" LIKE %Lennon% ESCAPE '\' 
)

Which can be translated as:

> select all blogs that contain an entry with “Lennon” in the headline as 
> well as an entry that was published in 2008
>

More from the docs:

> Suppose there is only one blog that had both entries containing “Lennon” 
> and entries from 2008, but that none of the entries from 2008 contained 
> “Lennon”. The first query would not return any blogs, but the second query 
> would return that one blog.
>
> In the second example, the first filter restricts the queryset to all 
> those blogs linked to entries with “Lennon” in the headline. The second 
> filter restricts the set of blogs further to those that are also linked to 
> entries that were published in 2008. The entries selected by the second 
> filter may or may not be the same as the entries in the first filter. We 
> are filtering the Blog items with each filter statement, not the Entry 
> items.


Sometimes we need several JOINs over the same table, sometimes we don't. 
And this is the way to achieve it. You want a single JOIN, put everything 
into a single .filter call, if you want multiple JOINs, use multiple 
.filter calls.

On Monday, April 3, 2017 at 2:33:28 PM UTC+3, Mahendra Gaur wrote:
>
> Thank you for reply.
>
> In case of second statement, why two JOIN are required each with single 
> filter ?
> As per my understanding whether it use one JOIN with both the filter or 
> two JOIN each with single filter, both are same.
> correct me if am wrong ?
>
>
>
> Thanks and Regards,
> Mahendra
>
> On Mon, Apr 3, 2017 at 1:39 PM, Todor Velichkov  > wrote:
>
>> The first one will use a single JOIN on the entry table, and will apply 
>> both filters to that table.
>> The second one will JOIN the entry table twice, and for every join will 
>> apply only a single filter
>>
>>
>> On Sunday, April 2, 2017 at 5:41:29 PM UTC+3, Mahendra Gaur wrote:
>>>
>>> Hello everyone,
>>>
>>> I am newbie to django. Now-a-days am reading django docs.
>>> While reading models i got confusion that, What is the difference 
>>> between filter chaining and filter with multiple arguments.
>>> For example what is the diffrence between below two:
>>>
>>> Blog.objects.filter(entry__headline__contains='Lennon', 
>>> entry__pub_date__year=2008)
>>>
>>> Blog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)
>>>
>>>
>>> can some one please help me to understand how these both works and most 
>>> importantly what will be corresponding MYSQL queries for above two 
>>> statements ?
>>>
>>>
>>>
>>> Thanks and Regards,
>>> Mahendra
>>>
>>> -- 
>> 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/19f4e103-0325-4f8e-bd03-502a1f2fe002%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/e25257a6-96b8-4c88-8699-32b6a0b38d0d%40googlegroups.com.
For more options, visit http

Re: Will function based views ever be deprecated?

2017-04-03 Thread Andréas Kühne

I really think you should revisit CBV's - you don't have to use the generic
views unless they make sense. I regularly override most of my own with
mixins and the like. And like you said - querying the database and
returning a template is probably one of the most common things I do. That's
a detail view and 3 rows of code.

I understand that you like the way you work - but I think CBV's is probably
one of the greatest additions to django - mostly because of mixins and
inheritance.

Regarding the need to use 2 forms in the same view - I haven't stumbled
across that usecase yet - but I probably wouldn't have an issue in CBV's
either - but couldn't use the generic FormView for that though.

Regards,

Andréas

2017-04-03 19:01 GMT+02:00 Some Developer :

> Most views are incredibly simple. Query database, maybe do a security
> check on the logged in user if the data shouldn't be public or only some
> users / groups can view it (yeah one thing I don't use as often as I should
> but will be using more of in the future is the built in Django permissions
> system), return data and add it to template context. Done.
>
> Forms might add a couple of minutes per form. Just need to check that each
> form is valid and save the results or do the database search as required.
> Neither requires much programming time or skill.
>
> I don't see why any of that should take any more than 5 minutes. Before I
> started programming in Python / Django I was a C programmer. Now that takes
> time because there are so many mistakes you can make in C unless you are on
> the ball. In comparison Python and Django is a piece of cake.
>
> The thing that takes the time is planning out features and making sure
> your unit tests are comprehensive. Also making sure your models are well
> designed. I can easily spend 2 times the amount of time planning out
> features than I do actually programming and my philosophy when it comes to
> programming is have the absolute bear minimum of code in your views. If you
> can get rid of code then do so.
>
> On 03/04/2017 16:10, Vijay Khemlani wrote:
>
>>
>> Also
>>
>> "I can write just about any view I want in less than 5 minutes with a
>> function based view. The only slow down on my end is my typing speed."
>>
>> If your typing speed is the limiting factor in your workflow... *shudders*
>>
>>
>
> --
> 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/ms
> gid/django-users/30a5eab2-dee9-eaff-66e4-105ba85bf0bf%40googlemail.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/CAK4qSCfh-P3ZHqjuhE8v%3DRgcbWQ32rJMDQBQEn_UTTTkJnv_8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Andrew Pinkham

There's a little bit of vocabulary overload going on that I can't help but 
point out, as it confused me when I encountered it.

There is a difference between Class-Based Views (CBV) and Generic Class-Based 
Views (GCBV). They were both introduced at the same time, and so it is easy to 
get them confused, but they serve very different purposes.

When referring to CBV, there is actually only a single CBV, called View. Every 
other class-based view provided by Django is a generic view! The goal of these 
views is to provide pre-defined, slightly-customizable behavior. The fact that 
they are objects (class-based) is secondary. They are called GCBV for 
historical reasons: to make a difference between the generic view _functions_ 
that preceded them.

As James points out, a view is simply a Python callable that receives a request 
and returns a response. To that extent, the View class and function views are 
_almost_ equivalent. View provides two extra things over a function view: (1) 
automatic handling of the OPTIONS HTTP method and (2) denial of HTTP methods 
not explicitly defined. The methods defined on subclasses of View map directly 
to HTTP verbs. As developers define class methods named after HTTP methods, 
View will automatically change the response returned by an OPTIONS request and 
allow those methods to return data.

Of course, a function view can be implemented to handle OPTIONS and deny HTTP 
methods not explicitly implemented. Django even provides a decorator for the 
latter, linked below.

https://docs.djangoproject.com/en/stable/topics/http/decorators/#django.views.decorators.http.require_http_methods

My personal opinion is that language is power, and I find the terms Class-Based 
Views and Generic Class-Based Views misleading. I'd prefer to simply call the 
latter Generic Views, as their object nature is not their utility. In an 
attempt to distance the documentation from the CBV vs GCBV, I'd consider 
calling View instances and subclass-instances "Object Views". That said, when I 
suggested this at DjangoCon US 2015, my suggestions seemed polarizing, so make 
of this what you will.

I feel pretty strongly about this topic, and gave a talk about it at the same 
conference: https://www.youtube.com/watch?v=BJiOERA49ZQ

I hope this is helpful!
Andrew
http://jambonsw.com
http://django-unleashed.com



-- 
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/BD0905CB-9D16-4F9A-8CBD-7115B3E46303%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

DATABASE DICTIONARY in Settings.py

2017-04-03 Thread alkhairohr

Hey everyone,

I'm new to Django and web development overall so please bare with me. I may 
be asking an incredibly stupid question. 

In the DATABASES dictionary in settings.py:

DATABASES = {
'default': {
'NAME': 'something',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'blahblah'
}

Is it possible for me to add more then one user and password? I am working with 
a team and we all have seperate mysql users. Also, is it preferred to just have 
one super user for Django?

-- 
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/075b8505-df99-425f-8fc8-0873f6f78c64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

channels/redis exception: TypeError: init() got an unexpected keyword argument 'socket_connect_timeout'

2017-04-03 Thread jpic

Hi all !

TypeError is raised when asgi_redis tries to open a connection to redis:

```
Traceback (most recent call last):
  
  File "/code/src/event/log.py", line 39, in emit
message(level, source, msg, relations, json, datetime, trace)
  File "/usr/local/lib/python2.7/dist-packages/channels/channel.py", line 
44, in send
self.channel_layer.send(self.name, content)
  File "/usr/local/lib/python2.7/dist-packages/asgi_redis/core.py", line 
168, in send
client=connection,
  File "/usr/local/lib/python2.7/dist-packages/redis/client.py", line 2694, 
in __call__
return client.evalsha(self.sha, len(keys), *args)
  File "/usr/local/lib/python2.7/dist-packages/redis/client.py", line 1944, 
in evalsha
return self.execute_command('EVALSHA', sha, numkeys, *keys_and_args)
  File "/usr/local/lib/python2.7/dist-packages/redis/client.py", line 570, 
in execute_command
connection = pool.get_connection(command_name, **options)
  File "/usr/local/lib/python2.7/dist-packages/redis/connection.py", line 
897, in get_connection
connection = self.make_connection()
  File "/usr/local/lib/python2.7/dist-packages/redis/connection.py", line 
906, in make_connection
return self.connection_class(**self.connection_kwargs)
TypeError: __init__() got an unexpected keyword argument 
'socket_connect_timeout'
```

It looks like there's some package version incompatibility, any clue is 
welcome :)

OS: Ubuntu Xenial
Channels: 1.1.2
Daphne: 1.2.0
Django: 1.10.6
Twisted: 17.1.0
asgi_redis: 1.2.1
redis pip package: 2.10.5

This issue seems pretty similar 
too: https://github.com/celery/celery/issues/2903#issuecomment-210632688

-- 
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/837d5a23-51fa-4f2b-a266-c826baa82728%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DATABASE DICTIONARY in Settings.py

2017-04-03 Thread Mike Dewhirst

On 4/04/2017 5:50 AM, alkhair...@mymail.vcu.edu wrote:

Hey everyone,

I'm new to Django and web development overall so please bare with me.
I may be asking an incredibly stupid question.

In the DATABASES dictionary in settings.py:

DATABASES = {
'default': {
'NAME': 'something',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'blahblah'
}
Is it possible for me to add more then one user and password?

Yes. You need a separate settings file per user. In development you can
and perhaps should all have different settings anyway. Inherit the base
settings and overload the DATABASES dict individually.

I am working with a team and we all have seperate mysql users. Also,
is it preferred to just have one super user for Django?

Depends. Go with what works for you.

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/075b8505-df99-425f-8fc8-0873f6f78c64%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/480fbd46-8479-0d49-35f2-77d5f353ee9e%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer

I'm about to start a new website and I'll make it a point to use some 
generic class based views when I think they are appropriate. I'll also 
try and move my custom user application that I use for all of my 
projects over to class based views as wells. Especially as the login() 
and logout() functions are being deprecated in the next release and 
being replace with class based views.


I'm sure I'll get the hang of them. I think the main problem I have is 
that I haven't memorised them yet. I've pretty much memorised everything 
that I need to do with function based views (with a few exceptions which 
are not that hard to look up). I guess once I have memorised everything 
that I need to know I'll be back being productive with them.


Hopefully it all goes OK :).

On 03/04/2017 21:09, Andréas Kühne wrote:

I really think you should revisit CBV's - you don't have to use the
generic views unless they make sense. I regularly override most of my
own with mixins and the like. And like you said - querying the database
and returning a template is probably one of the most common things I do.
That's a detail view and 3 rows of code.

I understand that you like the way you work - but I think CBV's is
probably one of the greatest additions to django - mostly because of
mixins and inheritance.

Regarding the need to use 2 forms in the same view - I haven't stumbled
across that usecase yet - but I probably wouldn't have an issue in CBV's
either - but couldn't use the generic FormView for that though.

Regards,

Andréas




--
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/f0d0f32e-b1ca-5076-20c6-63ff7feb8d9b%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Some Developer


Ah, that clears things up somewhat.

I can certainly start using the basic View class straight away and can 
slowly start moving over to the generic class based views as time 
permits and as I get more used to them.


The base View class sounds like it has all the advantages of function 
based views whilst having just enough in the way of features to make it 
useful.


As I said in the post I just made I'm just about to start a new website 
and I'll give class based views a go with that. I'll aslo try and move 
my user application over to them to see how it works.


On 03/04/2017 22:24, Andrew Pinkham wrote:

There's a little bit of vocabulary overload going on that I can't help but 
point out, as it confused me when I encountered it.

There is a difference between Class-Based Views (CBV) and Generic Class-Based 
Views (GCBV). They were both introduced at the same time, and so it is easy to 
get them confused, but they serve very different purposes.

When referring to CBV, there is actually only a single CBV, called View. Every 
other class-based view provided by Django is a generic view! The goal of these 
views is to provide pre-defined, slightly-customizable behavior. The fact that 
they are objects (class-based) is secondary. They are called GCBV for 
historical reasons: to make a difference between the generic view _functions_ 
that preceded them.

As James points out, a view is simply a Python callable that receives a request 
and returns a response. To that extent, the View class and function views are 
_almost_ equivalent. View provides two extra things over a function view: (1) 
automatic handling of the OPTIONS HTTP method and (2) denial of HTTP methods 
not explicitly defined. The methods defined on subclasses of View map directly 
to HTTP verbs. As developers define class methods named after HTTP methods, 
View will automatically change the response returned by an OPTIONS request and 
allow those methods to return data.

Of course, a function view can be implemented to handle OPTIONS and deny HTTP 
methods not explicitly implemented. Django even provides a decorator for the 
latter, linked below.

https://docs.djangoproject.com/en/stable/topics/http/decorators/#django.views.decorators.http.require_http_methods

My personal opinion is that language is power, and I find the terms Class-Based Views and 
Generic Class-Based Views misleading. I'd prefer to simply call the latter Generic Views, 
as their object nature is not their utility. In an attempt to distance the documentation 
from the CBV vs GCBV, I'd consider calling View instances and subclass-instances 
"Object Views". That said, when I suggested this at DjangoCon US 2015, my 
suggestions seemed polarizing, so make of this what you will.

I feel pretty strongly about this topic, and gave a talk about it at the same 
conference: https://www.youtube.com/watch?v=BJiOERA49ZQ

I hope this is helpful!
Andrew
http://jambonsw.com
http://django-unleashed.com





--
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/b17b7bb8-f33c-73fb-7054-ebed85928bfd%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Antonis Christofides

> I've just re-read my message and notice that it is extremely aggressive. I
> want to apologies for that. When I typed it I had just had a big argument with
> someone and it came across in my message to this list. That was uncalled for
> and I'm not normally that type of person. So sorry again. 
Hello,

I don't think you need to apologize. Your message was a bit agitated perhaps,
but I wouldn't call it aggressive. Agitated is fine—it goes straight to the
pain. I also liked the ensuing discussion, and I guess many people did, because
seeking the ideal structuring of the code is an endless quest.

Regards,

A.

Antonis Christofides
http://djangodeployment.com


On 04/03/2017 01:35 PM, Some Developer wrote:
> On 02/04/2017 04:37, Some Developer wrote:
>> Hi,
>>
>> I was wondering if function based views will ever be deprecated? I
>> absolutely hate class based views with a passion for various reasons
>> (too complex, trying to solve a problem that doesn't exist etc). With a
>> function based view I can write it in 2 minutes pretty much and handling
>> multiple forms on the same page is a piece of cake. The same is not true
>> of class based views. You need to look up which classes a certain class
>> based view inherits from to see what methods are available, handling
>> multiple forms on the same page is a pain in the arse if not impossible
>> and various other things that are just way more difficult than they
>> should be.
>>
>> So yeah. Are function based views ever going to go away? I've already
>> noticed that in Django 1.11 the login() and logout() functions are going
>> away in favour of class based views which seems silly as I'll have to
>> rewrite my perfectly working user app to use class based views now.
>>
>> Is that a sign of things to come? If that is what the developers are
>> planning can I please beg them to reconsider? Function based views are
>> just fine. You might prefer class based views but there are users out
>> there who much prefer function based views.
>>
>> Please don't take this as an aggressive post. I love working with Django
>> and I'm just passioniate about it. This isn't a flame post.
>>
>> Thank you for any help :).
>>
>> Some Developer.
>
> Hi,
>
> I've just re-read my message and notice that it is extremely aggressive. I
> want to apologies for that. When I typed it I had just had a big argument with
> someone and it came across in my message to this list. That was uncalled for
> and I'm not normally that type of person. So sorry again.
>
> If I post again I'll make sure to only do it when I am nice and happy :).
>
> Some Developer.
>

-- 
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/17e50dbf-0b40-12ec-f9f4-02a36b9d71a0%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.

Re: DATABASE DICTIONARY in Settings.py

2017-04-03 Thread Antonis Christofides

Hello,

this is far from an incredibly stupid question.

As you know, RDBMS's keep their own list of users and have sophisticated
permissions systems with which different users have different permissions on
different tables. This is particularly useful in desktop applications that
connect directly to the database. Web applications changed that. Instead of the
RDBMS managing the users and their permissions, we have a single RDBMS user as
which Django connects to the RDBMS, and this user has full permissions on the
database. The actual users and their permissions are managed by Django itself
(more precisely, by the included Django app django.contrib.auth), using database
tables created by Django. What a user can or cannot do is decided by Django, not
by the RDBMS. This is a pity because django.contrib.auth (or the equivalent in
other web frameworks) largely duplicates functionality that already exists in
the RDBMS, and because having the RDBMS check the permissions is more robust and
more secure. I believe that the reason web frameworks were developed this way is
independence from any specific RDBMS, but I don't really know.

So the canonical way of working is to have a single *database user* as which
Django logs on to the database, with full permissions on the database (including
permission to create and delete tables), and many *Django users*, each one with
different permissions. Typically only one Django superuser is created. I call
the superuser "admin", which I believe is the common practice.

You can probably do things differently, and maybe there exist custom database
backends that would allow you to switch the database user on login, but if
there's no compelling reason you should really stick to the canonical way.

Regards,

A.

Antonis Christofides
http://djangodeployment.com

On 04/03/2017 09:50 PM, alkhair...@mymail.vcu.edu wrote:
> Hey everyone,
>
> I'm new to Django and web development overall so please bare with me. I may be
> asking an incredibly stupid question. 
>
> In the DATABASES dictionary in settings.py:
>
> DATABASES = {
> 'default': {
> 'NAME': 'something',
> 'ENGINE': 'django.db.backends.mysql',
> 'USER': 'mysql_user',
> 'PASSWORD': 'blahblah'
> }
> Is it possible for me to add more then one user and password? I am working
> with a team and we all have seperate mysql users. Also, is it preferred to
> just have one super user for Django?
> -- 
> 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/075b8505-df99-425f-8fc8-0873f6f78c64%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/bb81345f-9799-f725-80bd-8e54f030b979%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

2017-04-03 Thread Jani Tiainen


Hi,

There also exists django-vanilla-views [1] which are a bit simplified 
version of generic class based views. You may find them easier to cope 
with (less magic).



[1] http://django-vanilla-views.org/

On 04.04.2017 01:59, Some Developer wrote:
I'm about to start a new website and I'll make it a point to use some 
generic class based views when I think they are appropriate. I'll also 
try and move my custom user application that I use for all of my 
projects over to class based views as wells. Especially as the login() 
and logout() functions are being deprecated in the next release and 
being replace with class based views.


I'm sure I'll get the hang of them. I think the main problem I have is 
that I haven't memorised them yet. I've pretty much memorised 
everything that I need to do with function based views (with a few 
exceptions which are not that hard to look up). I guess once I have 
memorised everything that I need to know I'll be back being productive 
with them.


Hopefully it all goes OK :).

On 03/04/2017 21:09, Andréas Kühne wrote:

I really think you should revisit CBV's - you don't have to use the
generic views unless they make sense. I regularly override most of my
own with mixins and the like. And like you said - querying the database
and returning a template is probably one of the most common things I do.
That's a detail view and 3 rows of code.

I understand that you like the way you work - but I think CBV's is
probably one of the greatest additions to django - mostly because of
mixins and inheritance.

Regarding the need to use 2 forms in the same view - I haven't stumbled
across that usecase yet - but I probably wouldn't have an issue in CBV's
either - but couldn't use the generic FormView for that though.

Regards,

Andréas






--
Jani Tiainen

--
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/ea745488-e56e-a027-dd4c-9cd63369bc66%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django SMTP Email backend error

2017-04-03 Thread Antonis Christofides

Hello,

Usually port 465 needs EMAIL_USE_SSL=True and EMAIL_USE_TLS=False. With port 587
it's usually opposite.

Regards,

A.

Antonis Christofides
http://djangodeployment.com

On 04/02/2017 03:13 PM, Bassam Ramadan wrote:
> i'm using the following backend
>
> EMAIL_BACKEND='django.core.mail.backends.smtp.EmailBackend'
> EMAIL_HOST='ams101.arvixeshared.com'
> EMAIL_PORT=465
> EMAIL_HOST_USER='my email'
> EMAIL_HOST_PASSWORD='my password'
> EMAIL_USE_TLS=True
>
> and im getting this error
>
> Exception Type: SMTPServerDisconnected at /email/
> Exception Value: Connection unexpectedly closed
> -- 
> 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/08e265e7-4c21-4f85-9dff-02fcdb5a5584%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/07fd2e95-7b22-ab08-52bc-955b7d2bf095%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.

Re: filter chaining v/s filter with multiple arguments.

Login/Logout, single instance only

Re: Login/Logout, single instance only

BDD in Django

Re: Cannot install channels

Re: filter chaining v/s filter with multiple arguments.

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

The Django server side shows http 400 and Invalid HTTP_HOST header message

RE: filter chaining v/s filter with multiple arguments.

RE: How to design High Scalability architecture with Django in cost effective fashion

Filter list dict in JsonField Postgres

RE: filter chaining v/s filter with multiple arguments.

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

Re: How to design High Scalability architecture with Django in cost effective fashion

RE: filter chaining v/s filter with multiple arguments.

Re: Will function based views ever be deprecated?

Re: filter chaining v/s filter with multiple arguments.

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

DATABASE DICTIONARY in Settings.py

channels/redis exception: TypeError: init() got an unexpected keyword argument 'socket_connect_timeout'

Re: DATABASE DICTIONARY in Settings.py

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

Re: Will function based views ever be deprecated?

Re: DATABASE DICTIONARY in Settings.py

Re: Will function based views ever be deprecated?

Re: Django SMTP Email backend error

32 matches

Site Navigation

Mail list logo

Footer information