

Django 1.7 Released - jsmeaton
https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/

======
themartorana
I can't say how much I love Django. Back in the day when it was first coming
out, I was coming out of the Microsoft/ASP.NET world and was being introduced
to the wonder of Rails. But a small project I had contributed some mind-share
to had been rebuilt in Django. When I asked which I should learn, Rails or
Django, a wise developer friend advised I play with Ruby and Python. Figure
out which _language_ spoke to me, and use the best framework available.

I chose python, and despite the niceties of Rails, found Django an absolute
pleasure. Add in a sprinkle of Johnny-cache, Jinja2, and South (because you
_could_ in Django) and it was a powerhouse.

I haven't written any Django code in a couple years now - my work is now
mostly backend/API code for which Flask was much lighter weight (and Go is
mostly replacing), but all my Django sites are still running.

Congrats to the team on continuing to push forward a brilliant framework, the
best documentation in the business, finally getting DB migrations in the core,
and more and more and more.

And by the way, thanks - I owe a bit (lot) of my success to everyone who
contributed to Django and the larger community. I hope my meager contributions
a few years back were at least a bit of repayment on a much larger bill.

~~~
lumpypua
Any suggestions on packages you're using for your Go toolchain?

I'm a django developer that's somewhat fed up with python's slowness. I love
django but I'm looking to diversify. I've worked through a bunch of Go
tutorials, but I don't have a good feel at all for the go ecosystem.

~~~
victorhooi
Yeah, the current web frameworks on Golang seem to be quite...chaotic to an
outsider. And the landscape is constantly changing.

It's not like Ruby or Python, which seem to have one clear mature do-
everything framework, and some more lightweight ones beneath.

Is there such a thing as a Django-equivalent in Golang at this point in time?
Or what's the closest analogue? None of them seem to package an ORM together,
so not sure what people tend to do here, to reduce boilerplate code in their
models.

~~~
crucialfelix
For many years in python there were several contenders for webframeworks. Only
after many years did Django eventually dominant.

I've used Django a lot and personally I would prefer smaller lightweight
frameworks where its easier to select packages that provide solutions to
specific problems. I'm not looking for the next Django. Something the size of
Express would be perfect.

~~~
jarpineh
I love Django for its docs and sensible defaults to just about everything.
I've been reading the Light Weight Django book, now nearing completion at
O'Reilly, and Django can be used as lightly as Express. I'd link to source
example, but I can't find the code anywhere and the ebook is not on this
device...

I don't know if it's lighter than regular Django in terms of speed, but by the
measure of how much you need to code you can't do much better. Couple of pain
points are declaring settings for middleware and template processors, even
when you don't really need them, but other than that it is really basic. This
is your URL pattern, this is your view function to call when a request comes
for such URL. From there you can do what you want with the request, as long as
you convert your response to Django's HttpResponse object (which takes a
string).

For something a bit different, I recommend taking a look into Morepath:
[http://morepath.readthedocs.org/en/latest/](http://morepath.readthedocs.org/en/latest/)

It looks to have some genuine useful parts from Zope, rethought for today's
more RESTful, Javascripted world. My next personal project will probably use
it as a base.

------
VuongN
I have to say that I've been a big Django user and have been using 1.7.x for a
bit in my own development. There are a couple of "oddities" for me that
perhaps folks will encounter:

1\. If you do heavy TDD, you might not like that fact that you can't skip
migrations the same way you previously could with SOUTH_TESTS_MIGRATE = False.
There's a thread going on ([https://groups.google.com/forum/#!topic/django-
developers/PW...](https://groups.google.com/forum/#!topic/django-
developers/PWPj3etj3-U)). It appears that with syncdb going away, there isn't
an option available. I really hope there's a way to retain syncdb for unittest
because I don't need to test database migration every time I run my quick
unittests.

2\. I think 'makemigrations' is a bit inconsistent at the moment. Sometimes it
creates more than 1 initial files, sometimes it creates just 1 (if you run
'makemigrations app-name' instead of 'makemigrations')

There are a couple of other general Django issues, but those are the things I
encountered while working with 1.7.x.

~~~
jsmeaton
1\. I think I'd like to see something like `./manage.py migrate --fresh`,
which would forget about existing migrations, create a set in memory, and
apply them. Pretty much emulating syncdb on a fresh database. Then the test
runner could use that behaviour optionally (otherwise, RunPython statements
may be missed that are required).

2\. It may create more than 1 migration file if there are specific ordered
dependencies afaik.

~~~
ProblemFactory
Does migration squashing do what you are looking for:
[https://docs.djangoproject.com/en/dev/topics/migrations/#squ...](https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-
migrations) ?

After squashing and migrating all existing databases, you can delete the old
migrations files. The squashed migration becomes the new fresh migration that
should usually contain just "CREATE TABLE" statements to be run on an empty
database.

------
zentrus
Awesome that migrations are now in Django core. I do see some pitfalls
regarding Historical Models though.

The problem is that application code usually changes over time. Consider a
deployment that hasn't been migrated in a long time. When migrations are
eventually run, the older migrations might assume application code behaved a
certain way. This is why you should _never_ use your regular application
models in migrations. Both South and Django 1.7 migrations copy "shallow"
versions of your models (no custom methods, save methods, etc), which helps to
encourage developers to keep the migration isolated from application models
that might change. The problem with Django 1.7 though is that these shallow
versions retain any inheritance they had at the time the migration was
written. So if that class goes away in the future, I presume the migration
will break. Worse yet, if the base class behavior changes, the migration run
later in time might behave differently than you intended.

For this reason, custom methods even from inheritance should not be saved in
the historical model. Only the fields should be saved off from the base
classes, and then merged into one class (remove any inherited classes). Any
other app code needed for the migration should be directly copied into the
migration itself.

~~~
andrewingram
I'm assuming that most of the pitfalls I wrote about a couple of years ago are
still applicable today, with either South or Django's own migrations:

[http://andrewingram.net/2012/dec/common-pitfalls-django-
sout...](http://andrewingram.net/2012/dec/common-pitfalls-django-south/)

~~~
zentrus
That's a good set of pitfalls to watch out for. Mainly, I just find it odd
that in Django 1.7, they are using frozen models to mitigate some of these
problems, but don't remove or freeze the base classes, therefore leaving the
same problem. I'm sure the migrations system will get better over time.

------
japhyr
I'm looking forward to the Django Dash, and hope to make time to put together
a small project using 1.7. I can't wait to try out the integrated migrations.

Thank you to everyone involved in getting this release out the door!

------
rectangletangle
Nice, cleaning up the whole model-manager and queryset redundancy makes it
much more DRY.

~~~
erichurkman
I'm definitely looking forward to deleting a fair amount of boilerplate code
that made this work in < 1.7.

~~~
rectangletangle
Same, Django's whole queryset API is really nice, but it's even nicer to
compose it with application specific methods. It's nice to be able to
centralize most queries to a single place in the code base, it's easier to
test, write, and read, and modify.

------
icn2
I haven't followed django for a while. Could someone explain a bit more about
django' model association part. Is it currently comparable to rails's model
associations? Looking at these two pages
[http://guides.rubyonrails.org/association_basics.html](http://guides.rubyonrails.org/association_basics.html)
[https://docs.djangoproject.com/en/dev/ref/models/relations/](https://docs.djangoproject.com/en/dev/ref/models/relations/)

It seems there are a bit more on rails model associations.

~~~
ubernostrum
You want this page:

[https://docs.djangoproject.com/en/1.7/ref/models/fields/#mod...](https://docs.djangoproject.com/en/1.7/ref/models/fields/#module-
django.db.models.fields.related)

In general:

Django's ForeignKey is equivalent to Rails' belongs_to.

Django's OneToOneField is equivalent to Rails' has_one.

Django's ManyToManyField is equivalent to Rails' has_and_belongs_to_many.

Also, in Django one generally only declares the relationship from one "side",
unlike Rails where the relationship is declared on both "sides" (i.e., in
Django one simply sets up a ForeignKey on A pointing to B, rather than placing
relationship identifiers on both A and B).

The equivalent of ":through" is also available.

Django has GenericForeignKey as an equivalent to Rails' polymorphic
associations.

~~~
jsmeaton
Just to clarify a little:

> Also, in Django one generally only declares the relationship from one
> "side", unlike Rails where the relationship is declared on both "sides"
> (i.e., in Django one simply sets up a ForeignKey on A pointing to B, rather
> than placing relationship identifiers on both A and B).

That's because django will automatically add the reverse of the relation to B,
so that you can access A through B. You can disable that functionality
optionally though.

------
ldng
Exciting release ! Could have been 2.0 to me with new migration system and
specially with the App loading revamp.

Is it me or AppConfig.ready() looks like a great place to put signals setup ?

~~~
teilo
.ready() is where you put pretty much _all_ app setup. There was never a good
place to do this before.

The app refactor is the single biggest improvement to Django in years. Bigger
than CBVs, IMO.

------
chhantyal
Time to start new project with it. I am thinking about Python 3 now :)

~~~
AndresRoot
Me too :)

------
shijie
Very much looking forward to using 1.7! Question for all: Would now be a good
time to move to Python 3.x? Our current Django installations are all running
2.7, and we are thinking about switching just for better unicode support
alone. I'd love to hear some of your thoughts on this.

~~~
mstrcnvs
Django fully supports Python 3 from version 1.5. If you can use it or not
depends more on the other packages you might have installed like DB adapters,
image processing, etc.
[https://caniusepython3.com](https://caniusepython3.com) is a good way to
know, you just need to drop your requirements.txt and it will tell you!

~~~
jsmeaton
Further, if you find a dependency that isn't supported, you should check the
projects site to see if support is on the road map. You could also try
contributing the python 3 upgrade to that package.

I recently began a new site based on django 1.7 (RC) and python 3.3, and only
a single package I needed wasn't available. Someone had already opened a PR
for py3 support though, so some gentle prodding got it merged within a week.

------
misiti3780
Super excited about having migrations built into Django finally!

Great work to everyone involved, and thanks for making an amazing product that
makes going to work fun

------
Demiurge
I really wish Django default doc site would default to latest production
version in urls. I have to keep changing dev to 1.6 and now 1.7

~~~
jsmeaton
If you open a bug in Trac the core team may be open to changing the default
behaviour.

[https://code.djangoproject.com/](https://code.djangoproject.com/)

------
kyllo
Good news, this means South now comes with Django by default. I use South in
every new Django project anyway, because database migration versioning is so
necessary.

~~~
stefantalpalaru
It's a backwards incompatible South successor:
[https://docs.djangoproject.com/en/1.7/topics/migrations/#upg...](https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-
from-south)

The upgrade path is to delete all your old migrations and create a new initial
one.

~~~
huxley
Andrew is providing some additions in South 1.0 to ease the transition a bit,
probably not to the degree he had hoped earlier in the process:

[http://south.readthedocs.org/en/latest/releasenotes/1.0.html](http://south.readthedocs.org/en/latest/releasenotes/1.0.html)

"As part of providing a migration path for authors of third-party apps and
libraries for Django, South will now first look for migrations in the
south_migrations directory, and then fall back to the migrations directory if
this is not found.

This is intended to alleviate the namespace clash between South and Django
migrations; prior to this, both were looking for a directory called
migrations, and so it was impossible to ship a third-party app with support
for both South and Django 1.7.

The recommendation is that you move your South migrations into the
south_migrations directory (existing users will not notice the change if they
upgrade South first), and then start a new set of Django 1.7 migrations in a
migrations directory (the default)."

~~~
radiac
How good are Django 1.7 migrations at detecting things which have already
happened? In particular, can you safely maintain South migrations alongside
Django ones, or do you have to force users to switch?

The problem I envisage is that when you add 1.7 support to your app, you move
your old migrations into south_migrations and start a clean migrations dir, as
the instructions say - but what happens when your next release makes a
database change? If you want to support all active versions (1.4, 1.6 and 1.7)
you'd have to add a South migration and a 1.7 migration to support both groups
of users - but then they no longer have a clean upgrade path from South to
1.7.

From reading the docs, it looks like 1.7 schema migrations may detect the
changes have already been made and skip over them, but what will happen when
you have data migrations too?

Does 1.7 figure out which operation you're up to by comparing your migrations
to the database state, and starting migrations once the two match? What if at
some point you return to an older set of model fields - does it match on the
earliest or the latest?

I plan on avoiding the issue as long as possible: get my apps as feature
complete as possible under South (with instructions for 1.7+ users for
creating their own migrations), then bump the version when I switch from South
to Django migrations. I'll then try to backport bugfixes to the South version
(as long as they don't change the db) until support for Django 1.4 and 1.6 are
dropped.

------
jMyles
It was cool to be at djangocon while this was announced in the hallway track.

~~~
techdragon
Best part of conferences is those wonderful unplanned moments. How's the mood
in the hallways there?

------
AndresRoot
Starting a new project with Django 1.7 and Python 3 :D

------
tbarbugli
cool, now we only need to wait another 5 years and we will see celery
integrated in Django :)

~~~
collyw
Celery is an overcomplicated mess with too many moving parts in my experience.
Django on the other hand works well and doesn't overcomplicate things.

------
smegel
Now if Hue would get off Django 1.2(?)...

------
jorgeer
Hallelujah!

------
nospecinterests
I am soo happy about this release I think my neighbors dog just went wee on
their floor!

