

Django 1.7 RC1 - jsmeaton
https://www.djangoproject.com/weblog/2014/jun/26/17rc1/

======
wiremine
Kudos to the Django team! Great to see it continue to improve.

Anyone know if there are any plans to update the HTML/CSS for the Admin app?
Functionally it rocks, but visually it feels like you're revisiting 2001. I'd
LOVE to see it rebuilt based on Zurb's Foundation or Bootstrap. I think we'd
see a lot of innovation inside the admin.

~~~
tragic
Grappelli[0] + django-filebrowser[1] = happiness. (Only gripe is it's not
responsive.)

[0] [http://grappelliproject.com/](http://grappelliproject.com/) [1]
[https://github.com/sehmaschine/django-
filebrowser](https://github.com/sehmaschine/django-filebrowser)

~~~
joeyspn
I always use django-admin-boostrapped for my django projects...

[https://github.com/django-admin-bootstrapped/django-admin-
bo...](https://github.com/django-admin-bootstrapped/django-admin-bootstrapped)

------
yuvadam
The 1.7 release is another great upgrade to the solid Django ecosystem.
Personally I am very much looking forward to native migrations (another step
forward from South, which by itself was awesome) as well as some of the new
custom QuerySet and Manager functionality.

That said, there seems to be a slight hiccup in third-party apps moving
towards 1.7, since those that have existing South migrations are in the
dilemma of whether to break backwards compatibility in moving to the native
migrations framework. Also there is a nice chunk of deprecated APIs (such as
@transaction.atomic) that many projects will throw warnings about now, until
those are patched.

Personaly, I've already started migrating projects to 1.7 in anticipation of
an upcoming release in the next few weeks.

Kudos!

~~~
avidal
Where do you see that @transaction.atomic is deprecated? It's not in the
release notes[1] and if I recall correctly, was only introduced in 1.6 as a
means to come up with a consistent API for nested transactions and savepoints.
Are you implying that it's deprecated as a decorator? Even if that's the case,
I still can't find a source.

[1]
[https://docs.djangoproject.com/en/dev/releases/1.7/](https://docs.djangoproject.com/en/dev/releases/1.7/)

~~~
yuvadam
Oops, I meant that commit_on_success() is deprecated in favor of atomic().

------
jicea
The big addition of the 1.7 is for me the Schema migrations
(rework/improvment/integration of South
[http://south.aeracode.org/docs/about.html](http://south.aeracode.org/docs/about.html)).
I really like Django, kudos to the team!

~~~
tomjen3
As a potential Django user all I can scream is finally. So annoying that they
didn't include those from the start.

~~~
zeograd
South was the defacto standard app to manage your schema, so it wasn't really
such a bad issue.

It's better to have it built in, sure, but it wasn't a nuisance before.

~~~
pandler
Other than being a little confused at first about why it wasn't included by
default, using south as a separate module is about as inconvenient as using
any other python package that isn't part of the standard library.

~~~
tragic
For people who know about it, yes. But probably the biggest win from pulling
it into core is that, here on in, a newbie will be told to get migrating stuff
from the first tutorial they do, and thus get working with this particular
best practice up front. Yes, it's always been pretty hard to do django for
more than 5 minutes without finding someone urging you to use South, but you
never know...

------
arrty88
I've always been a huge fan of Django and how productive it feels to build web
apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted
to migrate them to Django to save on licensing. I think the Django core is
strong enough to stand up to Microsoft.

~~~
orf
I used to love Django, but after using it for a couple of years I've got a bit
sick of it. The template language is horrible, as is the ORM. It's only
redeeming features is the forms framework (only just) and the admin panel.
That being said, it's super-awesome for getting a quick demo up or starting a
project with unclear requirements.

Edit: Why the downvotes? The templates are slow[1] and restrictive (no
function calls with parameters in templates. wat). and the ORM is utter
rubbish compared to SQLAlchemy. Django shines because it is convenient (and
there is a large ecosystem) - relationships are easy to configure and
everything just works together. Which is nice I guess, but it does force you
to use all of Django's inferior stuff.

1\. [http://tomforb.es/just-how-slow-are-django-
templates](http://tomforb.es/just-how-slow-are-django-templates)

~~~
jsmeaton
What do you not like about the ORM? It's one of my favourite pieces of django.

~~~
jawnb
The ORM is bad because it is a poor abstraction of SQL. This manifests itself
in several ways, the largest being little control over the SQL queries
generated.

Here's a gist I made the other day demonstrating this.
[https://gist.github.com/jawnb/cd7a899cac5300c01709](https://gist.github.com/jawnb/cd7a899cac5300c01709)

The poor abstraction really causes problems when you need to do anything
beyond the simplest of use cases. To achieve even modest performance gains,
you're better off hand writing your SQL. Additionally, doing even the most
trivial of trivial aggregate queries will also mean that you're hand writing
SQL.

SQLAlchemy is light years beyond the django ORM in this regard.

Don't take just my word for it though, here's a talk Alex Gaynor gave saying
the same things.
[https://www.youtube.com/watch?v=GxL9MnWlCwo](https://www.youtube.com/watch?v=GxL9MnWlCwo)

~~~
jsmeaton
I think the most important difference between Alchemy and Django is the
separation between the SQL abstraction layer and the ORM. There is no
separation with django, making it very difficult to really get in there and
make changes.

But I don't think this makes the django ORM bad. It is very easy for beginners
to get up and running. It is very easy to understand the models and the query
language.

As an FYI - 1.8 should make it possible to use .annotate() for constructs that
aren't aggregates - like functions and extra select columns. You'll also be
able to write more complex aggregates. It should give you greater control over
your SQL, removing the need for .extra() in most cases (but not .raw()). It's
what I've been working on recently:
[https://github.com/django/django/pull/2496](https://github.com/django/django/pull/2496)

------
gitaarik
I've been using the Django dev version (1.8) for a personal project for a
while now. I really like the built in migration framework, which is available
from this release (1.7). I think it's even easier and cleaner than South! Also
the documentation is very clear (as always).

There's just two commands [0]:

    
    
        makemigrations - to create migrations
        migrate - to (un)apply migrations
    

Adding migrations to an existing app is just running the `makemigrations`
command for that app [1]:

    
    
        python manage.py makemigrations your_app_label
    

It will create a migrations/ folder in the app folder and you're good to go.
When you change your models and run `makemigrations` again, it will make
migrations for the changes you made and you can apply them with the `migrate`
command. For migrations that can't be detected automatically (like renaming
models/fields) you can create an empty migration file (by supplying `--empty`
to the `makemigrations` command) and edit the migration file yourself. With
the great documentation this is easily done [2].

They also support data migrations (migration for the data in your database
instead of the scheme of the tables). So I think it replaces pretty much all
features of South. BTW, the original creator of South (Andrew Godwin) helped
create the migration framework in Django, so no hard feelings ;).

[0]
[https://docs.djangoproject.com/en/1.7/topics/migrations/#two...](https://docs.djangoproject.com/en/1.7/topics/migrations/#two-
commands)

[1]
[https://docs.djangoproject.com/en/1.7/topics/migrations/#add...](https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-
migrations-to-apps)

[2] [https://docs.djangoproject.com/en/1.7/ref/migration-
operatio...](https://docs.djangoproject.com/en/1.7/ref/migration-operations/)

------
sprite
A bit offtopic, but I was wondering what some good books/resources for
learning django are? I've mostly been using rails or sinatra for web stuff,
but planning on doing a project that I want to host on GAE and write with
django and django rest framework.

A friend recommended: [http://www.amazon.com/Two-Scoops-Django-Best-
Practices/dp/09...](http://www.amazon.com/Two-Scoops-Django-Best-
Practices/dp/098146730X/ref=sr_1_1?s=books&ie=UTF8&qid=1403886617&sr=1-1&keywords=django)
but looking for other recommendations as well.

~~~
softinio
Do not use Django with GAE. Really pointless to do this. You are better off
with Frameworks like Flask with GAE in my experience. To get the full benefit
of Django you really need to avoid GAE in my opinion

~~~
sprite
How come?

~~~
andrewfong
The big issue is that Django's ORM is built around traditional relational
databases, while Google App Engine is not. You can certainly make the two work
well enough together if you know what you're doing, but for someone just
getting started, it's an unnecessary exercise in frustration.

If you want to use GAE, I recommend just starting with web.py or whatever is
the default framework there. It's fairly easy to learn. If you need a place to
host Django, a good chunk of the Django documentation is dedicated to
discussing how to do that. There's also Heroku and what not as well.

~~~
sprite
So django-nonrel doesn't work well with GAE? [https://github.com/django-
nonrel/djangoappengine](https://github.com/django-nonrel/djangoappengine)

~~~
andrewfong
I haven't looked in a long time, but it probably works well enough. My point
is that much of the "batteries included" aspect assumes a relational database.
See, for example, the caveats django-norel makes with respect to the bundled
admin interface
([http://djangoappengine.readthedocs.org/en/latest/admin.html](http://djangoappengine.readthedocs.org/en/latest/admin.html)).
I suspect there are implications for the built-in user authentication and
permissions app as well.

That's not to say this isn't workable -- it's just that a lot of the Django
plugins, tutorials, and documentation out there will be far less useful to you
if you're starting with GAE.

------
dudus
Unfortunately AppEngine only includes django up to 1.5 I don't know why they
take so long to update their Third Party libs.

Of course you can include the lib yourself in the project but that's a burden
specially with large apps because you get restricted by the number of files
you can upload, so adding large libs is not the best world.

[https://developers.google.com/appengine/docs/python/tools/li...](https://developers.google.com/appengine/docs/python/tools/libraries27)

------
joeyspn
Do you think the upgrade from 1.6+south to 1.7 will be painful for small crud
projects? Can't wait to update to the 1.7 final version...

~~~
rajivm
Not unless you run into a library incompatibility with Django 1.7
(specifically, custom FileField's come to mind).

If you have few dependencies other than Django, the upgrade from South should
be fairly smooth. You essentially start your migrations from scratch: Delete
the South ones, let Django re-generate migration 0.

------
chdir
If I were to summarize Django: it's a godsend for new comers (the whole
package is fabulous & comprehensive with excellent documentation). It'll get
you to your destination fast & in style. But very soon, as you start getting a
hang of it, you'll realize that it's rigidity is wearing you out. I wish
there's a django-light fork that takes all the good things in it and mashes it
with jinja2 & SQLAlchemy.

 _Please_ make it a lot more modular. Maybe a kickstarter (like South did &
Postgres improvement is doing)

P.S. I know there's flask, but it's still a while before it reaches that point
for some of us.

~~~
mahmoudimus
One common theme I'm hearing is that individuals want a "way to grow big" but
with the ease of getting started quickly while having an extensive ecosystem.

Flask was written on top of Werkzeug as an example of how to build a "roll-
your-own" web framework. It has a few shortcomings, but overall, it's OK and
you can contour it to whatever you need done. After all, if Flask starts to
"wear you out," you can always graduate to just Werkzeug.

I think there's an opportunity here for something like this to be built on top
of Pyramid, which I've found to have a very extensible API. The main problem
with Pyramid is the perception to newcomers - there is more than one way to do
it and it doesn't have any opinions on how you should go about doing
something. It leaves it up to your imagination. There's a slight trade off
here between an opinionated framework and the extensibility of Pyramid.

~~~
jsmeaton
I think the problem with not being opinionated is that 3rd party libraries
have nothing they can rely on. Do you write 3 sets of templates for the 3 most
popular templating libraries? Do you provide models for SQLAlchemy AND Django?
Or do you pick your combination of dependencies, and let someone else
reimplement your library with a different combination?

That's where I think Django shines. It might not have the best templating
library, ORM, or routes frameworks. But app developers and library developers
know exactly what they have to integrate with. This encourages a better
ecosystem.

------
softinio
Loving the built in migrations with Django 1.7 inconjunction with builtin
virtualenv stuff with Python 3.4 :-)

~~~
rectangletangle
I love Python's batteries included philosophy. It's nice not to require 500+
dependencies just to write a simple fizzbuzz. It's _really_ nice to see Django
take this to heart.

------
dits59
Remarkable

------
skizm
I with Django would add the south project to their core. It seems like an
enormous oversight that you can't change data models after you sync them to
the DB for the first time without deleting all the data or using a 3rd party
app (south).

EDIT: I need to read things more carefully. My bad. Good job Django.

~~~
simonpantzare
That is one of the big things Django 1.7. "There's a new built-in schema-
migration framework."

~~~
tragic
Seriously.

They even made a t-shirt[1] punning on it.

[1] [http://teespring.com/django17-v2](http://teespring.com/django17-v2)

~~~
revo13
Aw man... Where can I get this now that the campaign has ended?

~~~
tragic
As I understand it, the smallest run they can do is 20. So if you can find 19
other people who missed out, they could run another campaign. I'd guess
Russell Keith Magee or someone else from the DSF would be the one to bother
about it.

~~~
freakboy3742
I'll save you the suspense - we've run the campaign twice, and we're not going
to run it again. Part of the sales gimmick was that it was the limited
availability.

But, fear not - given the success of the campaign this time, I think it's fair
to say that when the time comes, there will be a Django 1.8 release shirt.

------
channikhabra
Where do Django stand in the js everywhere fortresses of MEAN and damn awesome
stuff like meteor/derby? I mean it's possible to use django with client-side
js, precompiling js templates server side and using Django as REST backend or
use websockets layer on it and do stuff the modern apps should (arguably) be
doing i.e refresh-less UX, fast native-like apps, but still these major
server-side frameworks (django, ror and friends) are so much loved and used by
vast majority of "pros".

Most likely I am living in a bubble that making apps same language both sides
specially in frameworks like Meteor which revolutionises the workflow is the
best way to go.

Please break my bubble and enlighten me why we should still be using these
framweworks and not js only alternatives.

I don't mean to start a flame war (or may be I do), I just want my perspective
changed. It is sitting pretty stubbornly in my head that meteor like start-to-
end pipelined flows are the way to go (read all-sides javascript frameworks).

~~~
lmm
If you find using the same language in the browser and the server to be a
compelling advantage, js is your only option. But IME it's not actually that
big an advantage; most logic code belongs to one layer or another. For domain
objects (i.e. non-logic code) you can use something like protocol buffers and
then you can use the same object definition in both languages.

Advantages to me would be much more mature ORM support (e.g. others are
talking about how good the migrations are; there are some cool efforts in js
e.g. Knex but they're still very primitive in comparison to what Django can
now do automatically), better templating (certainly arguable, but I find none
of the js approaches encourage proper separation of markup and logic), and a
much more comfortable language for writing business logic in. Python has
nowhere near as many "gotchas" as js, and is much more readable for a less-
technical domain expert.

~~~
emidln
You can easily do this with Clojure/ClojureScript too. As I understand it,
it's also possible with Haxe. Theoretically, you could do the same with Ruby
or Scala too (not sure I've heard of other languages with reasonably complete
implementations that can handle both compile to native code (or a fast
interpreter) and compile to javascript).

