Re: difference between class based view and function based view

[Andrew Pinkham]

Django developers talk about three kinds of views:

- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)

People do not make always make the difference between CBV and GCBV, which is 
unfortunate, as they serve different purposes (naming things is hard). When 
Andréas states earlier in this thread that "(CBV) use a lot of defaults for 
populating your templates, forms and views" that is not 100% precise. He means 
GCBV---which provide default (generic) behavior---not CBV.

Let's break it down. Below is an example of a FV.

from django.http import HttpResponse
from django.views.decorators.http import (
require_http_methods
)

# below is equivalent to require_safe decorator
@require_http_methods(["GET", "HEAD"])
def hello_world(request):
"""Demonstrate HTTP Request/Response"""
return HttpResponse("Hello World")

Below is an example of an equivalent CBV.
 
from django.http import HttpResponse
from django.views import View
 
   class HelloWorld(View):
 """Demonstrate HTTP Request/Response"""

def get(self, request):
"""Handle GET HTTP method"""
return HttpResponse("Hello World")

Formally, a CBV is any class that inherits from View. The only difference 
between the two views above is that the View class being inherited will give 
you automatic handling of HTTP OPTIONS.

Stated otherwise: FV and CBV are *equivalent* with the exception of automatic 
OPTIONS handling in CBV.

GCBV are simply CBV that have been given behavior. For example, instead of 
programming a view that shows a template with model data, you can instead 
inherit a DetailView, and customize it by setting class variables and by 
overriding methods. For more about that, I recommend looking at 
https://ccbv.co.uk .

So, when should you use a FV, CBV, or GCBV?

If you are building a view that a GCBV provides behavior for, save yourself 
time and use it! It's easy to add or slightly modify GCBV behavior, but 
difficult to remove behavior. The moment you're thinking about removing 
something a GCBV does, stick to a function or CBV.

So then, for choosing between FV or CBV: Do you need to handle multiple HTTP 
methods? Is there shared behavior between how the resource is handled by those 
HTTP methods? If yes, a CBV can help organize that logic and avoid duplicate 
code.

However, if you have a simple view (typically only one or two HTTP methods must 
be handled), then a FV will serve you fine (remember the view decorators!).

If you're not sure, start with a FV, and then switch to a CBV or GCBV if 
appropriate (as complexity goes up or when you realize you can use a GCBV).

Hope that helps,
Andrew
https://jambonsw.com
https://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/C2853144-5CA1-4FAD-ACDF-C487AE8CE47E%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use Email to Login With Django Auth

[Andrew Pinkham]

You may be interested in django-improved-user, as it provides an email-based 
User model.

https://pypi.org/project/django-improved-user/

Full disclosure: I am one of the original authors. If you have any trouble with 
the package or documentation, please open an issue!

Andrew
https://jambonsw.com
https://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/D94CF79F-E8D0-48B8-9203-033C715EF0FC%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trigger actions independently of url request

[Andrew Pinkham]

On Oct 22, 2018, at 12:08, Charley Paulus  wrote:
> After reading the Django tutorial, my understanding (I hope I’m wrong) is 
> that the only way to trigger a function of a Django app is when someone on 
> the client side request the url related to that function.

That is correct. A view function/object is only called when a site visitor is 
routed to that callable by the URL configuration.

> But what if I want the server to run a function indenpendently of a url call, 
> for example:
> - every 10 minutes
> - when a pre-defined combination of variables become true

I'm not clear on your second condition, but you are probably interested in 
Celery for the first.

http://www.celeryproject.org/

Alternatively, some clouds provide the ability to run code on a regular basis. 
If your Django code is not closely coupled with cron job, you could use AWS 
Lambda.

https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html

If it is tightly coupled and Celery is too powerful for your needs, you could 
use an AWS Lambda (or Azure Function, etc) to send a request to your Django API 
on a regular basis.

Andrew
https://jambonsw.com
https://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/7DECDBA7-AF86-468C-A275-CC593CE10F0B%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need help with CDN on Django App using heroku

[Andrew Pinkham]

On Oct 22, 2018, at 11:53, Akash Purandare  wrote:
> However the issue is not with Whitenoise. Whitenoise can be used to serve 
> static files, yes. But how do I use it to serve media assets in the project?

Sorry, missed the media part.

Michal is right, you will need to install and configure django-storages for S3. 

https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html

Related:
https://docs.djangoproject.com/en/2.1/ref/settings/#media-root
https://docs.djangoproject.com/en/2.1/ref/settings/#media-url

This tutorial may be useful (Updated in 2017):

https://www.caktusgroup.com/blog/2014/11/10/Using-Amazon-S3-to-store-your-Django-sites-static-and-media-files/

Andrew
https://jambonsw.com
https://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/16D1C20E-91C9-4E16-B4E3-F410F815FA3D%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating seperate unique ids within the same table

[Andrew Pinkham]

On Oct 22, 2018, at 12:29, Matthew Pava  wrote:
> I am curious why you think it is anti-practice to expose primary keys for 
> user-visible purposes.
> My URLs all have the PK to the object in them, and any advanced user would be 
> able to “reverse engineer” a URL if they guess the PK of an object—and that’s 
> okay.

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet

> Even Django tutorials suggest using the PK in the URL of an object.

That's an interesting point, and I might argue is a shortcoming in the tutorial.

PRs welcome!

-- 
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/79D86944-B1A3-479B-8959-9477144EBA6F%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need help with CDN on Django App using heroku

[Andrew Pinkham]

https://devcenter.heroku.com/articles/django-assets
http://whitenoise.evans.io/en/stable/django.html

-- 
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/5027F5EE-03B2-4124-94CB-F88D4E42000E%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: generate username and password

[Andrew Pinkham]

Au sujet d'utilisateurs avec email comme pseudonyme, j’ai créé (avec Russell 
Keith-Magee) un projet qui a comme but de fournir des classes et modèles qui 
aident a la création d'utilisateurs custom.

https://django-improved-user.readthedocs.io/en/latest/quickstart.html
https://github.com/jambonsw/django-improved-user/

Si on parle de la façon d’enregistrer de nouveaux utilisateurs, le code dans 
django-registration serait peut-être utile aussi.

https://github.com/ubernostrum/django-registration

A savoir: la classe BaseUserManager vient avec une méthode make_random_password.

https://docs.djangoproject.com/en/2.1/topics/auth/customizing/#django.contrib.auth.models.BaseUserManager

Andrew
https://jambonsw.com 
https://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/39D445EA-C85C-4AD0-B169-A0C58CB7CE02%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: DjangoUnleashed-2.0

[Andrew Pinkham]

Hi,

I'm the author of Django Unleashed. A second edition is in the works, but it is 
taking some time (I'm also working on a video series).

Django 2.0 introduced a simplified system for URLs.

https://docs.djangoproject.com/en/2.0/releases/2.0/#simplified-url-routing-syntax

If you want wish to use the new syntax while following along with the examples 
in Django Unleashed, you have two choices.


Choice 1: replace regular expression syntax with the simplified syntax, using 
path matchers at the link below instead of regular expression patterns.

https://docs.djangoproject.com/en/2.0/topics/http/urls/#path-converters

In this case, the code below...

from django.conf.urls import url
...
url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', viewCallable)

would be replaced with...

from django.urls import path
...
path('articles', viewCallable)

Note that viewCallable is pseudocode for a function view or class-based view 
(viewClass.as_view()).

This involves changing every URL path (and now you know why the second edition 
is taking forever). Please note the new imports.


Choice 2: Use Django's new `re_path()` function instead of `url()` to fallback 
on original Django behavior.

In this case, the code below...

from django.conf.urls import url
...
url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', viewCallable)

would be replaced with...

from django.urls import re_path
...
re_path(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', viewCallable)

Only the function has changed: the regex pattern has not.

Read more about that at the link below.

https://docs.djangoproject.com/en/2.0/topics/http/urls/#using-regular-expressions


I might recommend using Choice 2 when following along with the book, but to 
give Choice 1 a whirl (after reading Django's documentation) on a new project 
as it's easier to read.

I hope this helps!

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/52151FC1-6C32-4D85-9C2C-199BC849CCB8%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-improved-user v1.0a1

[Andrew Pinkham]

Hi Joe,

I'm not 100% clear on what you mean by coordinating. Apologies if I miss the 
mark.

You should be able to use improved-user with both allauth and guardian (but I 
admit I have not tried!).

Allauth provides some notes on using a custom model, and covers how to use a 
model that doesn't have a username:

http://django-allauth.readthedocs.io/en/latest/advanced.html#custom-user-models

In Guardian's case, I would recommend subclassing 
improved-user.mixins.AbstractUser and guardian.mixins.GuardianUserMixin to 
create a new custom User model in your own project, rather than allowing 
guarding to monkey-patch the model. More about that at the links below:

https://django-guardian.readthedocs.io/en/stable/userguide/custom-user-model.html
https://github.com/django-guardian/django-guardian/blob/d8df846654634b93c3871d81d16304d553582e1b/guardian/mixins.py#L211

If you're wondering about whether improved-user will integrate the codebase 
with either of these, then the answer is no. With that said, I can see how a 
cookiecutter template that integrates all three of these tools together could 
be a time-saver to others, but do not have plans to create such a template and 
cannot currently commit to another project.

Hope this helps,
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/98F4117C-EB5E-48AB-AC3D-193694E4BC70%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-improved-user v1.0a1

[Andrew Pinkham]

Forgot to add links. >_<

https://github.com/jambonsw/django-improved-user
https://pypi.org/project/django-improved-user/1.0a1/
http://django-improved-user.readthedocs.io/en/latest/?badge=latest

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/1D6453E3-2D8F-4450-9D82-BE6B0786B38F%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

django-improved-user v1.0a1

[Andrew Pinkham]

Hi everyone!

Yesterday I released v1.0a1 of django-improved-user, which provides a custom 
Django user model with international identity handling and uses email as the 
username. 1.0a1 is feature complete and tested against Django 2.0a1 (as well as 
Django 1.8, 1.10, and 1.11).

I'm emailing the list to solicit feedback and review. The project is a 
collaboration between Russell Keith-Magee and myself based on our experience 
building custom User models (read more about that at 
http://django-improved-user.readthedocs.io/en/latest/rationale.html), and we'd 
like this to be helpful to the community.

I would therefore really appreciate any feedback!

Thanks you!
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/2D08565C-8637-4ADD-9212-9AAD7BBB9A9B%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will function based views ever be deprecated?

[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.

Re: What is the use of parent_template filter in Django templates

[Andrew Pinkham]

On Nov 1, 2016, at 10:26 AM, Prateek  wrote:
> I am reading Django Unleashed in which the author uses the following code to 
> extends the template
> 
> {% extends parent_template|default:"organizer/base_organizer.html" %}
> 
> What does parent_template do ?

Hi Prateek,
Thanks for buying my book!

The first time we use parent_template---a variable, not a template tag---is on 
page 108 of the book. The paragraph before Example 4.53 provides a full 
explanation of why I opt to use a variable with a default, rather than a magic 
(read: hardcoded) string.

Hope that's helpful!

Andrew

-- 
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/B2C78464-26BC-4BFF-89EB-155BACDD93B2%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Unleashed, custom user model

[Andrew Pinkham]

Hi Malik,

I'm sorry to hear that you are still having trouble with Chapter 22. I've 
attempted to answer your questions below based on the limited information you 
have provided. You might find a comparison with the book code helpful for 
future problems (https://github.com/jambonrose/DjangoUnleashed-1.8).

On Jul 5, 2016, at 9:49 PM, Malik Rumi  wrote:
> Why? a) you dumped the whole database, and b) you only did makemigrations for 
> the User app.

Please see the last half of page 564 for an explanation.

Short answer:
1. Before chapter 22, we created a migration for the Django User model.
2. We then swapped the model with a custom User model.
3. The original migrations thus use a model that is no longer relevant.
4. We must therefore completely replace the initial migrations.

It is simply easiest to delete the database, rather than untangle the mess 
we've made. One of the conclusions of Chapter 22 is that swapping in a Custom 
User Model is best done at the beginning of a project. Swapping a custom user 
model on a project in production is outside the scope of the book.

> I followed your example, but got this error
> 
> CommandError: Conflicting migrations detected; multiple leaf nodes in the 
> migration graph: (0002_profile, 0001_user in account). To fix them run 
> 'python manage.py makemigrations –merge'
> 
> What happened here? The only obvious difference between your examples and 
> mine is the Python version, and I don't see how that's relevant here. It 
> seems to be purely a Django migrations thing.

It is difficult for me to assess what went wrong without seeing any of your 
code and without any further information about what you've done. 

All of the code in the book is available online.

https://github.com/jambonrose/DjangoUnleashed-1.8

If you perform a diff of your project and the code at commit 19560085fc in the 
repo above, what differences are there? If you run the migration command on the 
repo above, do you get the same error? I am unable to replicate your issue.

https://github.com/jambonrose/DjangoUnleashed-1.8/commit/19560085fc

On Jul 7, 2016, at 12:39 PM, Malik Rumi  wrote:
> raise ValueError("Could not find common ancestor of %s" % migration_names)
> ValueError: Could not find common ancestor of set([u'0002_profile', 
> u'0001_user'])

This shows that there's something wrong with your migrations. How did you 
generate them? Did you delete the original ones first, as detailed on page 565? 
How does your project code compare to the book code online (see links above)?

> (cannon)malikarumi@Tetuoan2:~/Projects/cannon/jamf$ python manage.py make 
> migrations account

It looks like you changed the name of the user domain to account (I assume this 
is the same as user; there is no account domain in the book). Are you also 
changing the name of the domain in the code and the commands in the book? If 
not, this may be causing problems.

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/58D045A1-6C79-4A99-8839-6D6D68AC8263%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: "canonical" views.py in Django Unleashed book, Chapter 22

[Andrew Pinkham]

Hi Malik,

On Jun 30, 2016, at 11:00 PM, Malik Rumi  wrote:
> I found that surprising, but then I'm somewhat isolated so don't claim to 
> know what other folks are doing. Why is this the common practice? Just to 
> save time because the tools are available?

Yup - this is a general software practice: Why reinvent the wheel when it's 
available to you?

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/CE883CED-CEF1-4E70-B9E4-1620DF9F0DA8%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: "canonical" views.py in Django Unleashed book, Chapter 22

[Andrew Pinkham]

Hi Malik!
Thanks for buying my book! I'm glad to hear you like Django Unleashed, but I'm 
sorry you're frustrated with the github repo at 
https://github.com/jambonrose/DjangoUnleashed-1.8 .

Page xiv provides a quick explanation of git commits' relationship to the 
examples in the book. In short: each example in the book has a corresponding 
commit in the github repo (1+ examples per commit). This is why each example 
lists 'filename in hash' at the top of the example. If you suffix 
http://dju.link/ with a commit, it will take you to the diff on github.

For instance, in example 22.13 (which you referenced), the example is listed as 
being 'user/views.py in 83167965e8'. You can browse to 
http://dju.link/83167965e8 to be redirected to the diff of that commit on 
github, or else to http://dju.link/83167965e8/user/views.py to see the state of 
the file at that commit.

NB: if you browse the code on github without adjusting the commit, you're 
seeing the code as it is in Chapter 29 (Chapter 30 has no code in the repo).

If you don't want to browse github, you can also clone the repo, checkout 
commit 83167965e8, and then have the project to run directly on your computer!

Note that each commit message is prefixed with the Chapter that references it 
(such as 'Ch22: Create Profile Update web page.'). What's more, the sample 
gitconfig file in the repo comes with a few neat commands to make moving around 
the repo easier. See 
https://github.com/jambonrose/DjangoUnleashed-1.8#walking-the-repository for 
more info.

Now, to address some of your points directly:

> There is no core.utils or UpdateView in the github version

https://github.com/jambonrose/DjangoUnleashed-1.8/blob/master/core/utils.py#L5

> There is no PublicProfileDetail in the github version

http://dju.link/a1d420b17a
-> 
https://github.com/jambonrose/DjangoUnleashed-1.8/commit/a1d420b17a/

You can then browse to:
https://github.com/jambonrose/DjangoUnleashed-1.8/blob/a1d420b17a/user/views.py#L134

> Again, there is no PublicProfileDetail in the github version, which stops at 
> line 111

http://dju.link/a1d420b17a/user/urls.py
-> 
https://github.com/jambonrose/DjangoUnleashed-1.8/blob/a1d420b17a/user/urls.py

Relevant line is 114:
https://github.com/jambonrose/DjangoUnleashed-1.8/blob/a1d420b17a/user/urls.py#L114

I'm not super sure what you were looking at, or where the confusion occurred, 
but I would be open to your feedback about what you were seeing and how you got 
there, so that I may help others better get the code examples (as I spent *a 
lot* of time making the repo as cleans as possible given my deadlines). 

Hope that's helpful,
Andrew

-- 
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/86CD3FC7-D9F3-4705-9410-6275E6C93907%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

DjangoCon US 2016

[Andrew Pinkham]

We are pleased to announce that DjangoCon US will be hosted by the Wharton 
School at the University of Pennsylvania in Philadelphia from July 17-22!

The call for proposals is open! 
 We want to 
hear about your experience with and around Django. However, talks: 

- Don't need to be about Django specifically
- Don't need to be 100% fleshed out.
- Don't need to be about software directly
- Don't need to be advanced

Apply now! The deadline is April 18th. 

Never spoken before? Not a problem! There are speaker mentors that will help 
you (see the link above).

Is cost a concern? Not a problem! Apply for financial aid (deadline April 
25th). 

You can follow all the latest on Twitter .

Hope to see you in Philly!

Andrew

-- 
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/AE8F82AA-269C-473E-863D-6E6EAF242219%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative Amazon S3?

[Andrew Pinkham]

Heroku should be treated as the stateless portion of an app - do not store long 
term data there! (Same goes with services like EC2 and Digital Ocean.)

Rackspace and Microsoft have cloud alternatives to Amazon that may suit your 
purposes.

Hosting on a shared host like Dreamhost or A Small Orange are possibilities, 
but I wouldn't advise it; if you do decide on that route, I recommend looking 
into CDN services for distribution at that point.

Why does S3 not suit your purposes? Without knowing your goals, it's a little 
hard to advise.

Andrew

-- 
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/56E84256-64D6-481E-A917-98433340B30E%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Learning Django resources

[Andrew Pinkham]

Hi Robert,
You may be interested in my response to this question in another thread:

https://groups.google.com/d/msg/django-users/-iTZB7K1QI4/TTVXd9Y6EwAJ

Hope that helps,
Andrew

-- 
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/FB38E03C-DE51-4E9D-992F-3F20F1BB9466%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to learn Django stepwise Effectively

[Andrew Pinkham]

Hi Berbetto,
There are many resources for learning Django (NB: this email assumes you’re not 
looking to learn Python).

If you’re looking for free resources online, I would start with either the 
official tutorial, or the Django Girls tutorial.

https://docs.djangoproject.com/en/1.9/intro/tutorial01/
http://tutorial.djangogirls.org/en/index.html

There is also Mastering Django, which is an update on the Django Book (which is 
a little out of date, hence why I am not providing a link).

http://masteringdjango.com/django-book/

If you’re willing to pay money, you also have a number of books and resources.

To start, Hello Web App or Django Unleashed (disclaimer: I wrote the second 
one) are aimed at beginners.

https://hellowebapp.com/
https://django-unleashed.com/

Test-Driven Development with Python is also an excellent book that walks you 
through not only Django, but also testing with Django, which is essential. I 
tend to think of it as an excellent complement to the other beginner books.

http://shop.oreilly.com/product/0636920029533.do

Once you’re comfortable with the core concepts, you can move into more 
intermediate books, with Two Scoops of Django, Lightweight Django, and High 
Performance Django.

https://www.twoscoopspress.com/
http://shop.oreilly.com/product/0636920032502.do
https://highperformancedjango.com/

If books are not your thing, there are also excellent videos available from 
both Go Django and Treehouse.

https://godjango.com
https://teamtreehouse.com/library/Django-basics
https://teamtreehouse.com/library/customizing-django-templates

I’ve not taken the courses, but I’ve heard good things about Real Python:

https://realpython.com/courses/

I’m sure there are other resources out there that I have missed, but these are 
the ones that I know off the top of my head. I hope that helps!

Andrew

-- 
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/83CF501C-3EB3-4F32-B077-C10C3DC311A8%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

DjangoCon US 2015 Proposals Deadline

[Andrew Pinkham]

There are only 4 days left to submit a proposal to DjangoCon US 2015 
!

We want to hear about your experience with and around Django. However, talks: 

- Don't need to be about Django specifically
- Don't need to be 100% fleshed out.
- Don't need to be purely technical
- Don't need to be advanced

The conference isn't until September, so if you have a kernel of an idea, 
submit that! 

Never spoken before? Not a problem! There are speaker mentors that will help 
you .

Is cost a concern? Not a problem! Apply for financial aid 

 (deadline also May 15th for speakers).

There is no reason not to apply! Here are two articles to get you started.

- Writing a PyCon Proposal by Brian Curtin 

- How to Submit a Kickass Talk to otsconf (or any other conf for that matter) 
by the OpenTechSchool Conference 


As always, feel free to contact us !

Submit your proposals soon, and we hope to see you at DjangoCon US!

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/03C3A5AD-D660-4AA7-9B86-031FF0025B9D%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7.4, PostgreSQL: Migrate FK to M2M?

[Andrew Pinkham]

On Feb 19, 2015, at 11:54 AM, Tom Evans  wrote:
> Django accepts the keyword argument "null" on all fields, but it is
> meaningless for an M2M.

That is an excellent point. That's what I get for writing this up based on 
memory late at night.

Sorry for the error.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/BD03473D-D6FB-416F-9A64-8C19E948F805%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Doubt

[Andrew Pinkham]

On Feb 19, 2015, at 7:48 AM, sriraag paawan  wrote:
> Hello guys i am Paawan and i am new to Python Django.. i was getting an error 
> like "activate.bat is not recognised" when installing virtualenv. I am unable 
> to work with environment variable WORKON and version of Django... 

We need way more information to help you.

What system, version of Python? How are you installing virtualenv? What command 
creates the error? What is the full output of the error?

Frnakly, I would recommend Googling for the output of your error and using 
StackOverflow for help first. There are a lot of good answers there. I'm sure 
people on this mailing list will help, but this is really a better place to ask 
about Django rather than installation problems with virtualenv.

I also heartily recommend virtualenv_wrapper.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/12E67085-4307-48DF-AB24-325E3CE81DA6%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modify Installed_Apps settings

[Andrew Pinkham]

I am learning all sorts of things about Django's testing system (instead of 
actually getting work done).

The database schema is actually created via a call create_test_db() called on 
line 366 of setup_databases() in DiscoverRunner in django/test/runner.py. It's 
within this function, found in django/db/backends/base/creation.py, that 
migrate is called on available apps in Installed_Apps (via call_command!).

I was under the impression that code provided by TransactionTestCase was where 
the test database was (re-)created and destroyed throughout the lifetime of the 
test suite. As it turns out, while the code in TransactionTestCase loads and 
flushes data, it never touches the schema of the database (afaik).

This makes sense, as it seriously speeds up testing, as database creation is 
expensive.

Turns out, by simply overriding setUp and tearDown to use call_command with 
migrate, I can create the schema I desire.

# override/tests.py
from django.db import connections   

from django.test import TestCase, override_settings, modify_settings   
from django.core.management import call_command 

@override_settings(
ROOT_URLCONF='override.urls')
@modify_settings(
INSTALLED_APPS={'prepend': {'override'}})
class OverrideTests(TestCase):

def setUp(self):
super().setUp()
for db in connections:
call_command(
'migrate',
'override',
verbosity=0,
interactive=False,
database=db,
test_flush=True)

def tearDown(self):
for db in connections:
call_command(
'migrate',
'override',
'zero',
verbosity=0,
interactive=False,
database=db,
test_flush=True)
super().tearDown()

This is, of course, quite slow, as each of my tests results in a database 
schema change.

I'm thus trying to get this working with setUpClass and tearDownClass.

@classmethod
def setUpClass(cls):
super().setUpClass()
for db in connections:
call_command(
'migrate',
'override',
verbosity=0,
interactive=False,
database=db,
test_flush=True)

@classmethod
def tearDownClass(cls):
for db in connections:
call_command(
'migrate',
'override',
'zero',
verbosity=0,
interactive=False,
database=db,
test_flush=True)
super().tearDownClass()

My understanding of TransactionTestCase (and the interaction with the 
decorators) makes me think this is possible, but at the moment, I'm getting the 
following error:

django.core.management.base.CommandError: App 'override' does not have 
migrations (you cannot selectively sync unmigrated apps)

I am also uncertain if this is a good idea, as I'm not clear as to whether 
TestCase will flush the data in the unexpected table (ie: will tests methods 
still be isolated?).

Any help or ideas welcome.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/44D85C35-A483-47AB-891B-5631EB76D91E%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite3 to Postgres Migration?

[Andrew Pinkham]

On Feb 19, 2015, at 1:04 AM, talex  wrote:
> Am I correct that use of "python makemigrations" followed by
> "python migrate", should copy the existing data into Postgres
> and leave me with a working application?

I'm afraid not.

Migration allows for predictable and reversible alterations to the database 
structure. It's an excellent tool for modifying the schema (tables, columns) of 
a database. It is possible to use migrations for data (rows), but you typically 
need to modify the migration to achieve your goal.

Migrations are not intended for moving data from one database to another. You 
might be able to use Django to help achieve your goal, but it's not magic. To 
start with, you will need both both databases to be connected to your Django 
site - if you disconnect your SQLite database, then all the data in it is 
unavailable to you. Django won't know how to get to it anymore.

You might find my article about migrations interesting:
http://afrg.co/updj17/a2

> Instead what is happening is that "python migrate" gives
> the following error and hint:
> 
>  django.db.utils.ProgrammingError: column "date" cannot be cast automatically 
> to type integer
>  HINT:  Specify a USING expression to perform the conversion.
> 
> How can I apply this hint to make this work?

I'm unfamiliar with this error, but I suspect your problem lies in the 
migration files. What files exist in `/app_name/migrations/` ? Those are the 
files that `./manage.py migrate` execute with.

Andrew

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

Re: Django 1.7.4, PostgreSQL: Migrate FK to M2M?

[Andrew Pinkham]

Hi Micky,
When I had to migrate FK->M2M, I found that hand-hacking a migration file was 
the way to go. I wrote a multiple operation migration class that did the 
following:

1. create a M2M, nullable field, and set all defaults to null
2. use RunPython to run a function which takes the data from the FK field, and 
connects the objects in the M2M relation (bonus: create a function that does 
the opposite, to make this script totally reversible!)
3. remove the FK field
4. make the M2M field non-null (if desirable)

If you want the fields to be the same name, I think the safest bet is to 
prepend a step to the list above:

0. change name on FK field to temporary name

But I can't remember why I think that's better than changing the M2M field at 
the end.

I would share the code, but I can't find it at the moment. Sorry about that.

Hope that's helpful,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/11CFD73D-4B02-4B36-AE3C-7A5567D3C2A0%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modify Installed_Apps settings

[Andrew Pinkham]

Thanks for the info, Joel.

However, I'm trying to avoid creating a separate settings file. Any info about 
how to properly use modify_settings to add to installed apps or how to force 
the test runner to apply a specific migration would still be appreciated.

Thanks,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/53B86B68-0B7B-4121-9F7A-8F482BB9FCE7%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Modify Installed_Apps settings

[Andrew Pinkham]

I have an app in Django 1.7.4 that I would like to use purely for testing.

$ ./manage.py startapp override

The app contains its own model, view, and URL pattern (the model overrides a 
model in another app, allowing me to test behavior in a specific case).

For the moment, I have the app in INSTALLED_APPS, and the tests run fine. 
However, I would like to remove the app from INSTALLED_APPS, and override the 
setting just for the tests. In theory:

@modify_settings(INSTALLED_APPS={'append': 'override'})

However, if I then remove the string from project_name/settings.py, I am given 
a Python Traceback which ends in:

django.db.utils.OperationalError: no such table: override_modelname

How may I force the TestCase class to apply the migration file 
override/migrations/0001_initial.py to the test database? 

Thanks,
Andrew

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

Re: mark_safe and ValidationError params

[Andrew Pinkham]

Thanks for the input, Mike.

I actually think the behavior I showed here is a bug, and have started a thread 
on the developer mailing list to talk about it.

https://groups.google.com/d/topic/django-developers/hs1Ikc8Tuuk/discussion

Andrew

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

mark_safe and ValidationError params

[Andrew Pinkham]

I'm currently running Django 1.7.4. Provided the following clean function on a 
form:

def clean_slug(self):
new_slug = self.cleaned_data['slug'].lower()
if new_slug == 'invalid_value':
raise ValidationError(
# _ is ugettext 
mark_safe(_('SlugField may not be '
  '"%(slug_value)s" '
  'for URL reasons.')),
params={
'slug_value':
mark_safe('invalid_value')})
return new_slug


I expect the HTML error output to read:

SlugField may not be create_list for URL 
reasons.

Instead, the HTML output is: 

SlugField may not be codecreate_list/code 
for URL reasons.

Meaning, the user sees the  tags as opposed to having them output as HTML.

The problem occurs when I remove the call to ugettext as well, and while I 
expect to only need to apply mark_safe to the value in params, I apply the 
function to all of the text above.

Am I doing something silly? How do I properly apply mark_safe to text passed to 
params of exceptions? What is the best-practice here?

Thanks,
Andrew

PS
I promise to add a code to my ValidationError before committing.

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
Upgrading Django (to 1.7) Part IV: Upgrade Strategies is now available!

For the article:
 afrg.co/updj17/a4/

For all of the material:
 afrg.co/updj17/

I've also provided a checklist of upgrade steps, as well as a list of all the 
links used throughout the series:
 afrg.co/updj17/cl/
 afrg.co/updj17/l/ 

Any feedback appreciated. I hope you find the material helpful.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/73E604D5-964A-48CE-A0ED-F0856DE5AD2B%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
I have just updated Upgrading Django (to 1.7) Part III: Django 1.7's New 
Features. The App Registry and System Check Framework sections have been 
updated to be more accessible.

For the article:
 afrg.co/updj17/a3/

For all of the material:
 afrg.co/updj17/

Part IV will be available before the end of the day!

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/76C8501F-6735-4734-974A-119EE2614B07%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
Thanks to feedback from Fred and a few others, I've started editing Part III to 
make it more accessible.

Part IV was originally set to be published today. Unfortunately, it is not 
ready to be published.

As soon as the new Part III and Part IV are available, I will let you know.

Thanks,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/04813DD6-5BFF-4F90-981C-807383798DEB%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi Fred,
Thanks again for the positive feedback!

I'm sorry I lost you at the App Registry section. I'm afraid I can't recommend 
an article to help with the topic, either. Given your questions, I can see I 
missed the mark. Let me give it another go (warning: this is neither 
technically reviewed nor copy edited).

Django uses the `INSTALLED_APPS` setting to find all of the apps in a project, 
and to build a list of apps to run and use, called an app registry. The way 
Django builds the app registry has changed radically from Django 1.6 to Django 
1.7.

Django 1.6 (and before, but I admit I don't know how far back) used the 
`AppCache` class to maintain a list of these apps. The system was problematic 
because each `AppCache` instance shared state - any change to one `AppCache` 
object lead to a change in all `AppCache` objects. Because of migrations (and 
the need for historical/frozen models), the `AppCache` had to change in Django 
1.7.

Django 1.7 now provides an `Apps` class to be the app registry. Each instance 
is separate from others, allowing the migration system to build historical apps 
and models. You can fetch the `Apps` object (not class!) for your own project 
with:

from django.apps import apps as django_apps

Referred to as the master registry (the app registry for your project as it 
runs), `django_apps` is an instance of `Apps`, which contains a list of 
`AppConfig` objects.

Starting in Django 1.7 all apps now have an `AppConfig` object attached to 
them. These are built automatically by Django, meaning many developers will be 
able to get away without ever creating an `/app_name/apps.py` file for their 
projects. The ability to override `AppConfig`, however, is quite useful. It 
allows for the implementation of a `ready()` method (seen in the admin 
`AppConfig` subclass) as well as the ability to explicitly set the app label, 
allowing developers to easily rectify namespace conflicts.

Note that we avoid a namespace error thanks to `as django_apps` with 
`AppConfig`. I recommend you do this even if there is no namespace error.

from django.apps import apps as django_apps
from . import apps

To deal with this list of `AppConfig` objects (and the models within), all 
`Apps` instances sport a brand new API. We saw it throughout Part II and Part 
III of the article, using it to help us with data migrations and to build our 
checks. 

The only trick with `Apps` is that it must be fully built and configured before 
Django can take certain actions, including loading the custom user model, or 
using parts of the translation system. I touched a little bit on it in Part 
III, but plan to expand on it in Part IV.

The bottom line is that the app registry works mostly in the background by 
building a master registry and performing many of its key functions without 
developers ever knowing (just as many developers never knew about Django 1.6's 
`AppCache`). However, understanding the system even a little allows for the 
developer to better edit migrations and create checks, and I suspect that 
interacting with apps via this API will become commonplace.

Fred: Is the above helpful? Feel free to ask more questions.

On Oct 9, 2014, at 4:53 PM, Fred Stluka  wrote:
> Otherwise, can you suggest where I can find an article similar to 
> yours that gets me from 1.4 to 1.5 and on to 1.6 before I use 
> yours to get me from 1.6 to 1.7?


No, but I hope the process I lay out in Part IV will help you indirectly.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/46921726-891C-4AD3-8B12-88459761D52D%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
Upgrading Django (to 1.7) Part III: Django 1.7's New Features is now available!

For the article:
  afrg.co/updj17/a3/

For all of the material:
  afrg.co/updj17/

Any feedback appreciated. I hope you find the material helpful.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/584D6068-4D08-4E57-A10F-82E43BFF2E04%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi Fred,
Thanks again for the input! Glad you liked Part II.

Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Stodge,
Part II focuses on migrations, and deals in passing with AppConfig objects via 
data-migrations. Part III will take a closer look at the app registry, as we 
will create a custom AppConfig objects for `roundtable`. There is a (very) 
short section in Part III about import problems caused by custom user settings. 
I do not supply a solution to the problem, as every project will have a 
different solution, and the section is simply meant to let developers know of 
the potential problem.

I think your issue may be related. The issue is that Django must build the app 
registry before it can take (some) other actions. You likely have a problem in 
your import sequence. This should not prevent you from upgrading to 1.7. If you 
provide the traceback of the error and the associated code, I (or the mailing 
list) may be able to help figure out the problem.

I hope my article series provides some insight about the app registry, as well.

Hope that helps,
Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Carsten,
Thank you for reading and for the positive feedback!

Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
Upgrading Django (to 1.7) Part II: Migrations in Django 1.6 and 1.7 is now 
available!

For the article:
   afrg.co/updj17/a2/

For all of the material:
   afrg.co/updj17/

Any feedback appreciated. I hope you find the material helpful.

Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi Bob,
Thank you!

I spend a lot of Part II talking about schema and data migrations in both South 
and native Django 1.7 migrations. When building data migrations, you should be 
using historical models. In Django 1.7, you can request these models directly 
from the app registry built on the fly by the migration system and passed to 
the methods specified in the `RunPython` operation. This avoids using the 
models as they exist in the `models.py` file. This is similar to South's 
requirement you use the `orm` variable to interact with models, as Fred 
mentions.

If you would like more depth on the topic, then Part II is for you. If you 
would like to explore the topic before Wednesday, this is material available in 
the video. The code in the slides and github repo may be quite helpful as well.

afrg.co/updj17

Data migrations and schema migrations should play very well with each other. As 
I mentioned to Sabine, the only instance I had any difficulty was when I 
squashed migrations. As I had been alternating systematically between schema 
migrations and data migrations, the automatic squash tool was unhelpful. 
Thankfully, as the migration files are now easy to edit, I had absolutely no 
issue modifying the squash migration file myself.

Unfortunately, I do not go into detail about this in the article. Hopefully, 
the number of times we directly modify the migration files will allow people to 
figure this out for themselves. If that is not the case, and enough people ask, 
I will happily write a short article about the process.

If you have any questions about data migrations after reading Part II, please 
ask them here!

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/27F0C6E5-1DEC-4C79-A3AD-59005A801B1A%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Benjamin,
Thank you!

The next two parts of the article will focus on why certain changes were made. 
Please let me know if you think there were changes that I should have written 
about. Depending on my schedule and feedback, I would be willing to consider 
adding to the material if I've missed anything.

I'm happy to expand on my opinion if desired, but I don't think the 
documentation should have history/background sections. The documentation is 
already an enormous amount of work, and I like the fact that is sticks to being 
reference documentation.

However, I think the emails from Aymeric Augustin, Russell Keith-Magee, and 
Christopher Medrela documenting their work are incredibly helpful. Andrew 
Godwin even kept a blog! I would love it if people continued this trend. I will 
be linking to their work in Part III because of how useful and interesting the 
emails/blog-posts are. I think we owe them all a huge thank you for the effort.

Finally, the wiki contains some historical/background documents. I would not be 
averse to more pages like that, nor would I be averse to the release notes 
pointing to the emails mentioned above.

Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Fred,
Thank you!

Good luck with the upgrade!

Andrew

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

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi Sabine,
Thank you! It is really nice getting positive feedback.

The migrations section (Part II next week!) is a very basic introduction, aimed 
at people who have never used South or native migrations. One of the key 
takeaways (hopefully) of the article is the fact that it is easy to manually 
edit migrations, and that you are encouraged to do so.

Concerning early development cycles and migration reset, if you are pre-deploy, 
you currently have three options:
- disable migrations entirely during early development (will cease to be 
possible in Django 1.9; **inadvisable**)
- `squashmigrations` once models are ready
- delete all migrations and start from scratch once models are ready

I would recommend one of last two. The choice really comes down to how your 
engineering team is set up. If you are in a position where you can get the 
change to everyone at once, then the third option is viable (but keep a 
backup!). However, if you have independent developers, this may be 
dangerous/frustrating, and `squashmigrations` is likely a better option. The 
`squashmigrations` command is also what you should use in the long term. I do 
not cover it's use, but you may find the following documentation worthwhile:

https://docs.djangoproject.com/en/1.7/topics/migrations/#squashing-migrations

Unfortunately, I will not cover the admin in my article. Personally, I prefer 
the command line, as I am able to mover more quickly than the admin panel. This 
is completely subjective, of course, and not a criticism of the admin. For 
testing data, however, you may find data migrations to be useful in some 
situations, and I advise for their use. Part II will walk through multiple data 
migrations implementations in both Django 1.6 and Django 1.7.

Note that data migrations cannot be automatically squashed. If you use data 
migrations, this will result in migration file editing down the line. This 
should not be a problem, but I also don't want that to surprise you.

I hope this and future articles are helpful! Thanks again for the positive 
feedback.

Andrew

PS
I do not mind if you share my article. In fact, I would be delighted if you 
did. Please do!

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

Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
I am writing a series of articles based on the presentation I gave at DjangoCon 
US 2014. I put the first article online earlier today, and figured members of 
this list might be interested in the material.

For all of the material:
afrg.co/updj17/

For the article:
afrg.co/updj17/a1/

I plan to post the next three in the series on each of the coming Wednesdays.

Any feedback appreciated. I hope you find the material helpful.

Andrew

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

Re: Right way to create proxy to User model in Django 1.7

[Andrew Pinkham]

Hi Izabella,
Could you provide your custom user model declaration?

According the the documentation, you should be inheriting from 
`AbstractBaseUser`.

https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model

https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser

JJ Zolper and Russel Keith Magee recently posted about a custom email user on 
the Django Developer mailing list. You may find the code useful:

https://github.com/freakboy3742/django/commit/f54da396a0be09550d69625e1215119dfb4898e4#diff-49fc6cea24d46bdb27339c1aab392e32R379

Note that the code inherits not only from `AbstractBaseUser`, but also from a 
`PermissionsMixin`, which may or may not be desirable for you.

Hope that helps,
Andrew

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

Re: Three Django forms in different tabs in one template?

[Andrew Pinkham]

Hi Franco, Faridul, Stodge,

There are actually quite a few problems being asked. I've split them up into 
discrete questions.

1. Can a single view function print three forms in a template?

Yes.

WARNING: I am coding all of this off the top of my head. The code is likely 
riddled with typos and errors. Sorry. Hopefully the example will demonstrate 
enough of the idea.

# VIEW FUNCTION
# Start by invoking the forms you want
# remember to pass POST or initial data if necessary 
form1 = FormClassOne()
# etc for as many forms as you'd like.

# Create a Context or Request Context
c = Context({"foo": [form1, form2, form3]})

# or, more easily, use the `render` shortcut
render(
request,
template_name_vsr,
{'forms' : [form1, form2, form3]})

# TEMPLATE

{% for form in forms %}
  

{% csrf_token %}
{{ form.as_p }}


  
{% endfor %}


2. How should I handle the submission process (POST data)? With one view 
function, or with three view functions?

Both are valid ways of doing it, but I heavily favor the method with three POST 
processing views. The reason is that by combining all this logic in one 
location, you are increasing the complexity of your site drastically. Debugging 
that will be no fun in the event of a problem. Having a place where the forms 
are as simple as possible is quite desirable. Remember to write tests.

I would recommend starting with the three view method, and then moving into the 
single view function method, if so desired.

3. How do I program three view functions to handle POST requests from forms in 
a single view function?

Start by creating a basic view function that handles both the GET (display of 
form) and POST (submission of data) for all of the forms (just as you would 
regularly). A Generic Class Based View might be all you need here, but it might 
be wise to start with a simple Class Based View.

Now, simply point the forms above to these webpage urls. There are many ways to 
do this. I would consider: (1) adding the action URL to the form class as an 
instance variable, or else (2) simply building the URL in the single form view 
and passing it to the URL.

Note: you may have/want to account for the URL referring to these forms. I am 
fuzzy on the details

Consider that having a separate view/page for each form will help debug any 
issues, as you have a place where the complexity of the form/view is as low as 
possible.

4. How do I program a single view function to handle POST requests from all 
three forms?

The first problem is that you need to know which form has been submitted from 
the single view page. Using a hidden form field may provide that information, 
or checking the keys of the POST querydict may also work. However, in both 
cases, you are relying on information provided by the user, which is a Bad 
Idea. This is the biggest reason not to follow this method.

However, once you know which form is being submitted, you may then process it 
according to the rules set forth in the three views your previously programmed. 
Remember to adhere to DRY (ie: split the functionality into small, reusable 
pieces)!

I realize that's a lot of info, but again, there was quite a lot being asked. I 
hope that helps clarify the issue.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/24D6792A-4316-4806-8D10-470EAD15BCFD%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: models get_absolute_url issue

[Andrew Pinkham]

Hi Eddilbert,
What are the URL patterns for the two views? I suspect a problem with 
`pk_url_kwarg`, but I am surprised by the error output.

If that is not the problem: Does this error occur if you do not override the 
`form_class` of `ResourceCreateView`? Could you supply the code for 
`CreateResourceForm`?

Also, you may find the following site helpful when dealing with Generic Class 
Based Views (which allowed me to quickly check the behavior of get_object, 
listed in your traceback): http://ccbv.co.uk/

Andrew

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

Re: extremely slow django migrations

[Andrew Pinkham]

On Sep 10, 2014, at 12:25 PM, John Schmitt  wrote:
> Which file?  What do I look for?  What do I 'verify' and to what should it be 
> compared?

When you run `makemigrations app_name`, the output will inform you of the 
creation of at least one migration file, typically in 
project_name/app_name/migrations. You may look in this(/these) file(s), and 
ensure that the changes made are the changes you intended on your models.

The documentation allows for understanding of the new files:

https://docs.djangoproject.com/en/1.7/topics/migrations/
https://docs.djangoproject.com/en/1.7/ref/migration-operations/

Note that the verification step is entirely optional. The check is not to 
ensure that migrations work properly. The check is so that you can check that 
the changes you made in your models are the ones you intended.

If you've worked with South, the workflow for working with with native 
migrations is nearly identical.

Hope that helps,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/37C62F62-4DEF-4EBA-9A7D-5E0108824397%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: extremely slow django migrations

[Andrew Pinkham]

Hi Jesse,
Yes, in certain cases, native Django migrations may run very slowly.

https://code.djangoproject.com/ticket/22608

My understanding is that this should not be a problem unless you have a huge 
number of apps and models (note how the second benchmark from Paul in the 
ticket has 200 models).

If migrations are running very slowly for you, I would recommend sticking with 
Django 1.6 and using South first. The upgrade strategy at this point should be:

- upgrade your dependencies to the latest versions (Python, third party apps, 
etc)
- ensure that the dependencies work with Django 1.7 (Python 2.7, Python 3.2+, 
etc)
- Attempt upgrade
- test (and fix)
- test again
- do migrations run super slowly? Revert to Django 1.6 and South, wait for 
Django 1.7.1 (expected fix).

Quick heads up: `syncdb` is deprecated in Django 1.7. If you're using Django 
1.7, you should first call `makemigrations`, verify the contents of the file, 
and then call `migrate` to build/alter the database. However, despite 
deprecation, `syncdb` should not be having an effect on your migration speeds.

Hope that helps,
Andrew

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

Re: settings.py

[Andrew Pinkham]

Hi Ngangsia,

On Sep 8, 2014, at 12:16 PM, ngangsia akumbo  wrote:
> when i run the 
> django-admin.py startproject this is the settings file i have

I've glanced through the file. It looks fine to me, but I may have missed 
something.

> Please i need some help here dont understand what is going on

Are you following the tutorial? Are you experiencing a problem in particular? 
We need a little bit more information before we can help you.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/92EAC67F-B01D-4869-9BDC-0DDCA281A752%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Constants values and best practices

[Andrew Pinkham]

Hi Julian,

I think there are a couple options.

The easiest would be to store the constants as Python. I would recommend using 
the choices field, as detailed by the documentation:

https://docs.djangoproject.com/en/1.7/ref/models/fields/#choices

If you must store your constants as part of the database, and would like to 
keep the constants up to date across multiple databases/developers, you should 
look into data migrations. South provides them, as do the new migrations in 
Django 1.7 (I believe).

http://south.readthedocs.org/en/latest/tutorial/part3.html

Hope that helps,
Andrew

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