15 ms·

Django 1.11 Released

348 points by andrewingram 10y ago

andrewingram 10y ago
Quick link to release notes: https://docs.djangoproject.com/en/1.11/releases/1.11/ https://docs.djangoproject.com/en/1.11/releases/1.11/
rattray 10y ago
The new index definitions look nice: from django.db import models class Customer(models.Model): first_name = models.CharField(max_length=100) last_name = models.CharField(max_length=100) class Meta: indexes = [ models.Index(fields=['last_name', 'first_name']), models.Index(fields=['first_name'], name='first_name_idx'), ] Also supports ordering (eg; `'-first_name'` for DESC) and `BrinIndex`/`GinIndex`.
- ddorian43 10y ago
  Damn, those are new ? Or did just the formating change?
  - chc 10y ago
    You previously couldn't define the name or type of an index. You just listed tuples of fields to be indexed.
  - Alex3917 10y ago
    The old index syntax (e.g. unique=True) will still work, and is now considered a shortcut for the more verbose syntax. The idea is to have one standard syntax that supports creating non-btree indexes in the model definitions, rather than needing to create them via custom migrations.
  - scrollaway 10y ago
    Class-based db indexes are new.
  - ubernostrum 10y ago
    Bit of both. Previously, you could indicate you wanted an index on a field, but only on a single field, and you did it in the field definition. Declaring them in Meta via the Index class is new, as is the multi-field support and direction support. More importantly, you can subclass Index to define other types of indices besides the default (which is btree). For example, Django now ships built-in subclasses to do BRIN and GIN on Postgres.
    - deckiedan 10y ago
      Is there anywhere django docs on how to actually use the brin/gin indexes? All I can find is that they exist...
      - rattray 10y ago
        https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/indexes/#module-django.contrib.postgres.indexes https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/...
    - minusf 10y ago
      single field? what about `unique_together` and `index_together`?
- lsh 10y ago
  hm. 'indexes' will bother me. I've lived with 'color' vs 'colour' for a long time, perhaps I'll be ok.
mundanevoice 10y ago
Best Django release ever! Good thing we have 1 years overlap between two LTS releases (1.8 and 1.11). Will be upgrading my apps soon. :D
mxscho 10y ago
Note that 1.11.x is also the last major version to support Python 2.7, 2.0 will only run on Python 3.5+ iirc.
- TkTech 10y ago
  I imagine the last major official version. There are so many companies still stuck on 2.7 for various reasons that features will be forked and backported for at least 5 more years.
  - publicfig 10y ago
    Well, this is an LTS release, so it will be supported until 2020. By 2020, however, not only will Django 1.11 have reached End of Life, but Python 2.7 itself will have as well. Any company concerned with using a Django version past EOL will also have the same issue of supporting Python 2.7 past EOL
    - collinmanderson 10y ago
      Also, if a company is still stuck on Python 2.7 in 2020, there's a good chance probably already stuck on an older version of Django anyway.
nik736 10y ago
Anyone interested in explaining why I should choose Django over Rails nowadays? Or is this just a Python vs Ruby thing?
- sparkling 10y ago
  It boils down to Python vs Ruby. Overall, both frameworks are pretty similar and you can build a modern web application in both. Personally i think RoR is the slightly better framework (better defaults, easy test/dev/production setup, sane asset handling), but i prefer Python over Ruby, so i end up using Django.
  - scrollaway 10y ago
    As someone who hasn't used RoR, can you talk about the difference in asset handling?
    - debaserab2 10y ago
      Rails uses an asset pipeline package called sprockets. You throw everything in a special directory and it wraps it all up and packages it nicely for you. This also gives you SASS and coffee compilation by default. Sprockets handles minification and cache invalidation for you. If you don't mind the opinionated approach to your javascript and stylesheets, it works fine. If you just need to sprinkle in some javascript on top of your site, it's fantastic. If you intend for your app to be javascript heavy, a lot of people rip out sprockets altogether and fallback to webpack to handle asset compilation (and I believe the newer Rails version is integrating webpack to play nicer with the rest of the framework) I can speak from personal experience that Sprockets is a PITA if you want to use npm.
      - steveklabnik 10y ago
        > (and I believe the newer Rails version is integrating webpack to play nicer with the rest of the framework) Yup http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/ http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/
ubernostrum 10y ago
Unsure why the comment pointing this out is dead, but yes: this is the last release series of Django to support Python 2. The next major release of Django will be 2.0, which introduces a new release cadence and will only support Python 3. For those who are curious and don't feel like digging into the release-process documentation, the new system will consist of three point releases per major version. So 2.0, 2.1, 2.2, then 3.0, 3.1, 3.2, and so on. Each X.2 release will be an LTS. Compatibility policy will be that if you're running X.2, and get no deprecation warnings, you can upgrade direct to (X+1).2 without changing any code. Then when you clear any deprecation warnings that pop up post-upgrade, you're good to go for (X+2).2.
- emidln 10y ago
  Any pointers to documentation / discussion around the rationale for X.2 instead of X.0 or X.1? I'm sure there are very good reasons and would like to read them.
  - robertfw 10y ago
    I haven't seen it discussed but immediately it would appear that it would allow for new features introduced in x.0 to have the kinks worked out in the x.1 and x.2 releases, so the LTS ends up having the new features along with their fixes, and then you can move on to the next batch of bigger features
  - collinmanderson 10y ago
    Django almost went with X.0 as the LTS. Here's where X.2 was originally proposed: https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ https://groups.google.com/d/msg/django-developers/MTvOPDNQXL... Here's the final summary: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ The most breaking part of the the LTS cycle is right _after_ the LTS, so that's the best time to change the major version number.
ploggingdev 10y ago
As soon as I saw this post, I upgraded a project from Django 1.10.5 to Django 1.11 using this guide [1] and faced no issues at all. Deprecation warnings are displayed, but that's because third party packages need time to update. Great work Django devs! [1] https://docs.djangoproject.com/en/1.11/howto/upgrade-version/ https://docs.djangoproject.com/en/1.11/howto/upgrade-version...
- tclancy 10y ago
  If you want to upgrade from further back but are worried about it, I put together a guide to the biggest changes at each step from 1.3 on: http://thosecleverkids.com/thoughts/posts/upgrading-django http://thosecleverkids.com/thoughts/posts/upgrading-django
alexbecker 10y ago
They seem to be moving towards saner form rendering [0], which is nice. And they fixed at least one of their numerous footguns [1]. But I still think Django has too many footguns to be used for important projects [2]. [0] https://docs.djangoproject.com/en/1.11/ref/forms/renderers/ https://docs.djangoproject.com/en/1.11/ref/forms/renderers/ [1] https://docs.djangoproject.com/en/1.11/releases/1.11/#queryset-get-or-create-and-update-or-create-validate-arguments https://docs.djangoproject.com/en/1.11/releases/1.11/#querys... [2] https://alexcbecker.net/blog.html#django-is-terrible https://alexcbecker.net/blog.html#django-is-terrible
- deleted 10y ago
  [deleted]
- tedmiston 10y ago
  It's great that you've written a thoughtful critique about such nuanced and valid points, but from reading your post, it's not totally clear to me what you think are viable solutions to making (1) requests more atomic and (2) validation more intuitive. Regarding (3) testing complex dynamic templates, I don't have much input as I tend to build APIs using Django Rest Framework rather than web apps with Django templates. Perhaps serializers and validators in DRF solve some of your concerns. (I'd also be curious to hear what frameworks or libraries you've opted to use instead of Django for your use cases.)
  - alexbecker 10y ago
    I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transaction and perform a second get if it creates a new object, then rollback the transaction if more than one object is returned and use the other object instead (similarly rewrite update_or_create). I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms. I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it. For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.
cdnsteve 10y ago
LTS release, now I can assure business that we're good on this technology stack for 3 years. Thanks Django team!
- sbuttgereit 10y ago
  You know, when I look at their statement about this being an LTS, it seems (to my understanding) that they have a slightly different definition of what support means in this context. "This version has been designated as a long-term support (LTS) release, which means that security and data loss fixes will be applied for at least the next three years. It will also receive fixes for crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django for the next eight months until December 2017" I expect that something like a "crashing bug" would be something that would be supported in an LTS, but here they're specifically excluding such bugs from the full three year duration. If stability were a priority, I'm not sure I would look at this any differently than an 8 month release. To be fair, I don't work in this space, so I may have a skewed perspective, but the 8 month limitation items did catch me off guard.
  - collinmanderson 10y ago
    In theory Django doesn't guarantee to fix any non security/data-loss bugs after December, however in the past some other bugs have been fixed too. 1.8 had a similar timeline (December 2015 limitation), but there were some non security / data-loss bugs fixed in 2016: https://github.com/django/django/commits/stable/1.8.x/django?after=ba046f9994422c97751581cdae3ace17af2ffcb0+34 https://github.com/django/django/commits/stable/1.8.x/django...
  - jldugger 10y ago
    If you require longer support, you probably want to pay for such a thing. Does RHEL package django?
    - collinmanderson 10y ago
      It's in EPEL. Also, Django 1.11 will likely be in Ubuntu 18.04, supported until 2023.
RicCo386 10y ago
Last major release before Django 2.0 which will be Python 3 only. Looking forward to the __future__
- cheapsteak 10y ago
  I've been meaning to learn Django as it seems to have a much more mature ORM and migration capabilities (currently very much productive with node via Sequelize and Express, but migrations are rather tedious). Is now a good time or should I wait till 2 is out? How big of a break will it be? A friend also expressed that it might not be worth it to use Django if just for the ORM and migrations (backend is just api), is he right?
  - thehardsphere 10y ago
    > How big of a break will [Django 2.0] be? Not abnormally big at all if you're writing Python 3 code. The Django team is very good at communicating about planned changes in advance. Aside from dropping Python 2 support, the only reason they're calling it Django 2.0 is because they switched version numbering schemes to a modified version of SemVer. I would learn now if I were you. > A friend also expressed that it might not be worth it to use Django if just for the ORM and migrations (backend is just api), is he right? I'm not sure, because I don't know what the alternatives are for you (I dabble in Django on the side). But I do know that some people do use parts of Django instead of all three layers, so it may not be ridiculous.
    - cheapsteak 10y ago
      What is your main stack?
      - thehardsphere 10y ago
        Java EE et al. Specifically Spring/Hibernate in a web app that we distribute to customers for them to run themselves (usually in Tomcat). With a separate UI app that is finally almost finished transitioning from Flex to Javascript. Not the sort of thing I recommend unless you have an application that actually needs all of that (which our users do, and if you did I doubt you'd be looking at anything in Python).
swah 10y ago
If I'm consuming from an API instead of interacting with Postgres, does it make sense to use Django instead of something without "models" ?
- mkolodny 10y ago
  I'd highly, highly recommend Django REST Framework: http://www.django-rest-framework.org/ http://www.django-rest-framework.org/ It's built on top of Django, and makes creating APIs super easy.
  - swah 10y ago
    Ok, I'm actually looking at that for the last few days, but would make the same question replacing Django with DRF.
    - jcoby 10y ago
      I'm in your same situation and I think it really depends on your use case. Are you creating an API that's read-only and only for you or a small internal team? You could pretty easily write that in just about any framework (or even no framework at all). Once you start adding on features like allowing writes, authentication+authorization, rate limiting, API discovery, client library generation, OAuth support, etc then something like DRF really makes sense. DRF is pretty darn flexible and it uses Django so you get a lot of functionality for free, including the Django admin if you want a way to explore your data. DRF in no way forces you to use the Django models (or even any models at all).
    - theptip 10y ago
      I'd argue that for anything other than a very simple microservice that is going to remain static, DRF is the better choice. Its sweet spot is simple to moderately complex domain models, particularly CRUD-based APIs, where you get a _lot_ for free. It's great to be able to define a DB model, and in a few lines of code have the API endpoint for that DB entity up and running. When you start getting to complex apps, you may find yourself fighting against the framework somewhat in order to keep your concerns separated, but that's a Hard Problem in general, and so I don't think it's a flaw of the framework itself (though there are a few areas where DRF is opinionated that I think it should not be). If you were using Flask, you'd have more freedom to tweak things when you get to this point, but you'd also have spent 1.5x the dev effort building all of the things that Django/DRF does already. In short, if you don't know whether you need Django/DRF or Flask, you probably need Django/DRF. Once you have enough experience with Django/DRF to critique that stack's design decisions, you'll be in a position to make good decisions of your own with Flask if Django/DRF doesn't meet your needs.
funkdified 10y ago
Can all future posts of this nature use the title format: Django {version} unchained ?
theptip 10y ago
My main point of friction in Django is still the admin interface; it's got a very steep sigmoid of a learning curve. The easy stuff is very easy, which is great, but when you want to do something somewhat complex it becomes arcane very quickly, usually requiring step-debugging through the code to figure out which framework method needs to be tweaked. Also, it's 2017 and we are still selecting ForeignKeys from an unfiltered drop-down menu with potemtially thousands of entries? This is madness. A PR for using select2.js (https://github.com/django/django/pull/6385 https://github.com/django/django/pull/6385) has been floating around for a year now, but progress is glacial. I fear the admin site code has become so flexible and generic that it's difficult to extend, which is discouraging improvements. Anyone care to shout out their favourite admin site replacements? I've tried a few but not found a great fit.
- gherig4 10y ago
  django-extensions is an automatic install for me with the shell_plus feature. They also support an admin FK autocomplete, http://django-extensions.readthedocs.io/en/latest/admin_extensions.html http://django-extensions.readthedocs.io/en/latest/admin_exte...
- jarcoal 10y ago
  It's not the best solution ever, but you might look into raw_id_fields to solve the dropdown issues. https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#django.contrib.admin.ModelAdmin.raw_id_fields https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#dj...
  - theptip 10y ago
    Yeah this is the best native workaround I'm aware of.
    - urda 10y ago
      Is it really a workaround, if it's already baked in as a feature though?
jamesmp98 10y ago
I'm surprised Django is still alive given the recent JavaScript-everything-must-be-a-client-webapp hype.
- AdamN 10y ago
  No biggie. We use Django Rest Framework to drive the API on top of Django and React as the front-end single page web app. Works great!
- avtar 10y ago
  Django REST Framework can still play a part in the scenario you describe. Additionally I found this thread and the linked post really helpful in thinking about how Django and something like React can work together, with some more nuances and variation covered beyond just looking at one part being a SPA (handling routing, etc.) and the other a REST backend: https://www.reddit.com/r/django/comments/5sar7l/reconciling_djangos_templatebased_mvc_model_with/ https://www.reddit.com/r/django/comments/5sar7l/reconciling_...
wenbert 10y ago
Does Django have an equivalent for Laravel's Homestead?
- collinmanderson 10y ago
  One thing that's similar is https://github.com/django/django-box https://github.com/django/django-box. It's a Vagrant box primarily intended for developing Django itself. It includes Postgres, MySQL, Memcached, Sphinx, Pillow, selenium, and multiple versions of Python.
- dguaraglia 10y ago
  Not sure that's really necessary with Django. Lavarel, like most PHP frameworks, require an HTTP server configured with just the right version of PHP, etc. just for development. Django is much simpler: - django-admin startproject MyProject - cd MyProject - python manage.py migrate - python manage.py runserver That should give you a very decent development server without requiring VirtualBox or anything like that. I'd recommend following the official tutorial if you want to give it a spin.
  - GoodbyeEarl 10y ago
    I've realized last week these simple steps to run a Django project, but, as I come from Node, I miss npm start.
    - StavrosK 10y ago
      What's the difference?
    - abdelhai 10y ago
      Why not use a Makefile or Invoke (written in Python) to achieve this?. That's what I have been doing.
  - wenbert 10y ago
    I really think it needs it. Although "start project" works as it is, I can't be bothered installing MySQL and configuring nginx - that takes a bit of time especially if you miss something. There should be something like this for Django with all the "de facto" tech that a dev might need.
truetuna 10y ago
It's been a while since I've used Django but at the time (I think 1.6) I couldn't figure out a way to do a migration like adding a non null column to a decent sized relation 100M records without having the table lock up. I use flyway now for db migrations and what's great is that I can perform migrations in multiple steps (because it's just SQL). So in this case, I can alter table and add a column with nullable, deploy my app to write to both, migrate data at a later time, deploy app again to stop writing to the old column, update column constraints and remove old column. Does Django ORM have this kind of flexibility?
- odonnellryan 10y ago
  Yeah you can write raw SQL with Django ORM or in the migrations.
cutler 10y ago
Can someone explain the results of recent Techempower benchmarks (https://www.techempower.com/benchmarks/#section=data-r13 https://www.techempower.com/benchmarks/#section=data-r13) which show Django 22 times faster than Rails for JSON serialisation, 4 times faster for multiple queries, 7 times faster with fortunes and 23 times faster handling plain text? If these results were true wouldn't Django have replaced Rails long ago?
- MaxfordAndSons 10y ago
  Because if raw performance is your main selection criteria for a web framework you shouldn't be using either of them.
bachstelze 10y ago
Are there plans for django 2.0 to support asynchronous processing like in http://aiohttp.readthedocs.io/en/stable/ http://aiohttp.readthedocs.io/en/stable/ ? Everybody suggests celery as an asynchrone task queue, but i dont see how to resolve a http request with it. Will this come with python 3 because the async/await syntax introduced by PEP 492 is only valid for Python 3.5+ ?
- fleetfox 10y ago
  And why would you want it? What is your use case? Making something async introduces a lot of complexity with no obvious benefit. It's also not as simple as it looks. For instance all db access in django is synchronous at the moment and changing that is not trivial since it requires swapping out whole layer. I don't read the mailing lists but i'm not sure if it's even considered. If you want async requests today you can take a look at channels: http://channels.readthedocs.io/en/latest/ http://channels.readthedocs.io/en/latest/
  - bachstelze 10y ago
    I want to return values from external REST APIs to the client. Is it really that hard with the new async/await syntax?

348 points by andrewingram 10y ago

Quick link to release notes: https://docs.djangoproject.com/en/1.11/releases/1.11/ https://docs.djangoproject.com/en/1.11/releases/1.11/

rattray 10y ago

The new index definitions look nice: from django.db import models class Customer(models.Model): first_name = models.CharField(max_length=100) last_name = models.CharField(max_length=100) class Meta: indexes = [ models.Index(fields=['last_name', 'first_name']), models.Index(fields=['first_name'], name='first_name_idx'), ] Also supports ordering (eg; `'-first_name'` for DESC) and `BrinIndex`/`GinIndex`.

ddorian43 10y ago
Damn, those are new ? Or did just the formating change?
- chc 10y ago
  You previously couldn't define the name or type of an index. You just listed tuples of fields to be indexed.
- Alex3917 10y ago
  The old index syntax (e.g. unique=True) will still work, and is now considered a shortcut for the more verbose syntax. The idea is to have one standard syntax that supports creating non-btree indexes in the model definitions, rather than needing to create them via custom migrations.
- scrollaway 10y ago
  Class-based db indexes are new.
- ubernostrum 10y ago
  Bit of both. Previously, you could indicate you wanted an index on a field, but only on a single field, and you did it in the field definition. Declaring them in Meta via the Index class is new, as is the multi-field support and direction support. More importantly, you can subclass Index to define other types of indices besides the default (which is btree). For example, Django now ships built-in subclasses to do BRIN and GIN on Postgres.
  - deckiedan 10y ago
    Is there anywhere django docs on how to actually use the brin/gin indexes? All I can find is that they exist...
    - rattray 10y ago
      https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/indexes/#module-django.contrib.postgres.indexes https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/...
  - minusf 10y ago
    single field? what about `unique_together` and `index_together`?
lsh 10y ago
hm. 'indexes' will bother me. I've lived with 'color' vs 'colour' for a long time, perhaps I'll be ok.

mundanevoice 10y ago

Best Django release ever! Good thing we have 1 years overlap between two LTS releases (1.8 and 1.11). Will be upgrading my apps soon. :D

mxscho 10y ago

Note that 1.11.x is also the last major version to support Python 2.7, 2.0 will only run on Python 3.5+ iirc.

TkTech 10y ago
I imagine the last major official version. There are so many companies still stuck on 2.7 for various reasons that features will be forked and backported for at least 5 more years.
- publicfig 10y ago
  Well, this is an LTS release, so it will be supported until 2020. By 2020, however, not only will Django 1.11 have reached End of Life, but Python 2.7 itself will have as well. Any company concerned with using a Django version past EOL will also have the same issue of supporting Python 2.7 past EOL
  - collinmanderson 10y ago
    Also, if a company is still stuck on Python 2.7 in 2020, there's a good chance probably already stuck on an older version of Django anyway.

nik736 10y ago

Anyone interested in explaining why I should choose Django over Rails nowadays? Or is this just a Python vs Ruby thing?

sparkling 10y ago
It boils down to Python vs Ruby. Overall, both frameworks are pretty similar and you can build a modern web application in both. Personally i think RoR is the slightly better framework (better defaults, easy test/dev/production setup, sane asset handling), but i prefer Python over Ruby, so i end up using Django.
- scrollaway 10y ago
  As someone who hasn't used RoR, can you talk about the difference in asset handling?
  - debaserab2 10y ago
    Rails uses an asset pipeline package called sprockets. You throw everything in a special directory and it wraps it all up and packages it nicely for you. This also gives you SASS and coffee compilation by default. Sprockets handles minification and cache invalidation for you. If you don't mind the opinionated approach to your javascript and stylesheets, it works fine. If you just need to sprinkle in some javascript on top of your site, it's fantastic. If you intend for your app to be javascript heavy, a lot of people rip out sprockets altogether and fallback to webpack to handle asset compilation (and I believe the newer Rails version is integrating webpack to play nicer with the rest of the framework) I can speak from personal experience that Sprockets is a PITA if you want to use npm.
    - steveklabnik 10y ago
      > (and I believe the newer Rails version is integrating webpack to play nicer with the rest of the framework) Yup http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/ http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/

ubernostrum 10y ago

Unsure why the comment pointing this out is dead, but yes: this is the last release series of Django to support Python 2. The next major release of Django will be 2.0, which introduces a new release cadence and will only support Python 3. For those who are curious and don't feel like digging into the release-process documentation, the new system will consist of three point releases per major version. So 2.0, 2.1, 2.2, then 3.0, 3.1, 3.2, and so on. Each X.2 release will be an LTS. Compatibility policy will be that if you're running X.2, and get no deprecation warnings, you can upgrade direct to (X+1).2 without changing any code. Then when you clear any deprecation warnings that pop up post-upgrade, you're good to go for (X+2).2.

emidln 10y ago
Any pointers to documentation / discussion around the rationale for X.2 instead of X.0 or X.1? I'm sure there are very good reasons and would like to read them.
- robertfw 10y ago
  I haven't seen it discussed but immediately it would appear that it would allow for new features introduced in x.0 to have the kinks worked out in the x.1 and x.2 releases, so the LTS ends up having the new features along with their fixes, and then you can move on to the next batch of bigger features
- collinmanderson 10y ago
  Django almost went with X.0 as the LTS. Here's where X.2 was originally proposed: https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ https://groups.google.com/d/msg/django-developers/MTvOPDNQXL... Here's the final summary: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ The most breaking part of the the LTS cycle is right _after_ the LTS, so that's the best time to change the major version number.

ploggingdev 10y ago

As soon as I saw this post, I upgraded a project from Django 1.10.5 to Django 1.11 using this guide [1] and faced no issues at all. Deprecation warnings are displayed, but that's because third party packages need time to update. Great work Django devs! [1] https://docs.djangoproject.com/en/1.11/howto/upgrade-version/ https://docs.djangoproject.com/en/1.11/howto/upgrade-version...

tclancy 10y ago
If you want to upgrade from further back but are worried about it, I put together a guide to the biggest changes at each step from 1.3 on: http://thosecleverkids.com/thoughts/posts/upgrading-django http://thosecleverkids.com/thoughts/posts/upgrading-django

alexbecker 10y ago

They seem to be moving towards saner form rendering [0], which is nice. And they fixed at least one of their numerous footguns [1]. But I still think Django has too many footguns to be used for important projects [2]. [0] https://docs.djangoproject.com/en/1.11/ref/forms/renderers/ https://docs.djangoproject.com/en/1.11/ref/forms/renderers/ [1] https://docs.djangoproject.com/en/1.11/releases/1.11/#queryset-get-or-create-and-update-or-create-validate-arguments https://docs.djangoproject.com/en/1.11/releases/1.11/#querys... [2] https://alexcbecker.net/blog.html#django-is-terrible https://alexcbecker.net/blog.html#django-is-terrible

deleted 10y ago
[deleted]
tedmiston 10y ago
It's great that you've written a thoughtful critique about such nuanced and valid points, but from reading your post, it's not totally clear to me what you think are viable solutions to making (1) requests more atomic and (2) validation more intuitive. Regarding (3) testing complex dynamic templates, I don't have much input as I tend to build APIs using Django Rest Framework rather than web apps with Django templates. Perhaps serializers and validators in DRF solve some of your concerns. (I'd also be curious to hear what frameworks or libraries you've opted to use instead of Django for your use cases.)
- alexbecker 10y ago
  I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transaction and perform a second get if it creates a new object, then rollback the transaction if more than one object is returned and use the other object instead (similarly rewrite update_or_create). I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms. I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it. For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.

cdnsteve 10y ago

LTS release, now I can assure business that we're good on this technology stack for 3 years. Thanks Django team!

sbuttgereit 10y ago
You know, when I look at their statement about this being an LTS, it seems (to my understanding) that they have a slightly different definition of what support means in this context. "This version has been designated as a long-term support (LTS) release, which means that security and data loss fixes will be applied for at least the next three years. It will also receive fixes for crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django for the next eight months until December 2017" I expect that something like a "crashing bug" would be something that would be supported in an LTS, but here they're specifically excluding such bugs from the full three year duration. If stability were a priority, I'm not sure I would look at this any differently than an 8 month release. To be fair, I don't work in this space, so I may have a skewed perspective, but the 8 month limitation items did catch me off guard.
- collinmanderson 10y ago
  In theory Django doesn't guarantee to fix any non security/data-loss bugs after December, however in the past some other bugs have been fixed too. 1.8 had a similar timeline (December 2015 limitation), but there were some non security / data-loss bugs fixed in 2016: https://github.com/django/django/commits/stable/1.8.x/django?after=ba046f9994422c97751581cdae3ace17af2ffcb0+34 https://github.com/django/django/commits/stable/1.8.x/django...
- jldugger 10y ago
  If you require longer support, you probably want to pay for such a thing. Does RHEL package django?
  - collinmanderson 10y ago
    It's in EPEL. Also, Django 1.11 will likely be in Ubuntu 18.04, supported until 2023.

RicCo386 10y ago

Last major release before Django 2.0 which will be Python 3 only. Looking forward to the __future__

cheapsteak 10y ago
I've been meaning to learn Django as it seems to have a much more mature ORM and migration capabilities (currently very much productive with node via Sequelize and Express, but migrations are rather tedious). Is now a good time or should I wait till 2 is out? How big of a break will it be? A friend also expressed that it might not be worth it to use Django if just for the ORM and migrations (backend is just api), is he right?
- thehardsphere 10y ago
  > How big of a break will [Django 2.0] be? Not abnormally big at all if you're writing Python 3 code. The Django team is very good at communicating about planned changes in advance. Aside from dropping Python 2 support, the only reason they're calling it Django 2.0 is because they switched version numbering schemes to a modified version of SemVer. I would learn now if I were you. > A friend also expressed that it might not be worth it to use Django if just for the ORM and migrations (backend is just api), is he right? I'm not sure, because I don't know what the alternatives are for you (I dabble in Django on the side). But I do know that some people do use parts of Django instead of all three layers, so it may not be ridiculous.
  - cheapsteak 10y ago
    What is your main stack?
    - thehardsphere 10y ago
      Java EE et al. Specifically Spring/Hibernate in a web app that we distribute to customers for them to run themselves (usually in Tomcat). With a separate UI app that is finally almost finished transitioning from Flex to Javascript. Not the sort of thing I recommend unless you have an application that actually needs all of that (which our users do, and if you did I doubt you'd be looking at anything in Python).

swah 10y ago

If I'm consuming from an API instead of interacting with Postgres, does it make sense to use Django instead of something without "models" ?

mkolodny 10y ago
I'd highly, highly recommend Django REST Framework: http://www.django-rest-framework.org/ http://www.django-rest-framework.org/ It's built on top of Django, and makes creating APIs super easy.
- swah 10y ago
  Ok, I'm actually looking at that for the last few days, but would make the same question replacing Django with DRF.
  - jcoby 10y ago
    I'm in your same situation and I think it really depends on your use case. Are you creating an API that's read-only and only for you or a small internal team? You could pretty easily write that in just about any framework (or even no framework at all). Once you start adding on features like allowing writes, authentication+authorization, rate limiting, API discovery, client library generation, OAuth support, etc then something like DRF really makes sense. DRF is pretty darn flexible and it uses Django so you get a lot of functionality for free, including the Django admin if you want a way to explore your data. DRF in no way forces you to use the Django models (or even any models at all).
  - theptip 10y ago
    I'd argue that for anything other than a very simple microservice that is going to remain static, DRF is the better choice. Its sweet spot is simple to moderately complex domain models, particularly CRUD-based APIs, where you get a _lot_ for free. It's great to be able to define a DB model, and in a few lines of code have the API endpoint for that DB entity up and running. When you start getting to complex apps, you may find yourself fighting against the framework somewhat in order to keep your concerns separated, but that's a Hard Problem in general, and so I don't think it's a flaw of the framework itself (though there are a few areas where DRF is opinionated that I think it should not be). If you were using Flask, you'd have more freedom to tweak things when you get to this point, but you'd also have spent 1.5x the dev effort building all of the things that Django/DRF does already. In short, if you don't know whether you need Django/DRF or Flask, you probably need Django/DRF. Once you have enough experience with Django/DRF to critique that stack's design decisions, you'll be in a position to make good decisions of your own with Flask if Django/DRF doesn't meet your needs.

funkdified 10y ago

Can all future posts of this nature use the title format: Django {version} unchained ?

theptip 10y ago

My main point of friction in Django is still the admin interface; it's got a very steep sigmoid of a learning curve. The easy stuff is very easy, which is great, but when you want to do something somewhat complex it becomes arcane very quickly, usually requiring step-debugging through the code to figure out which framework method needs to be tweaked. Also, it's 2017 and we are still selecting ForeignKeys from an unfiltered drop-down menu with potemtially thousands of entries? This is madness. A PR for using select2.js (https://github.com/django/django/pull/6385 https://github.com/django/django/pull/6385) has been floating around for a year now, but progress is glacial. I fear the admin site code has become so flexible and generic that it's difficult to extend, which is discouraging improvements. Anyone care to shout out their favourite admin site replacements? I've tried a few but not found a great fit.

gherig4 10y ago
django-extensions is an automatic install for me with the shell_plus feature. They also support an admin FK autocomplete, http://django-extensions.readthedocs.io/en/latest/admin_extensions.html http://django-extensions.readthedocs.io/en/latest/admin_exte...
jarcoal 10y ago
It's not the best solution ever, but you might look into raw_id_fields to solve the dropdown issues. https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#django.contrib.admin.ModelAdmin.raw_id_fields https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#dj...
- theptip 10y ago
  Yeah this is the best native workaround I'm aware of.
  - urda 10y ago
    Is it really a workaround, if it's already baked in as a feature though?

jamesmp98 10y ago

I'm surprised Django is still alive given the recent JavaScript-everything-must-be-a-client-webapp hype.

AdamN 10y ago
No biggie. We use Django Rest Framework to drive the API on top of Django and React as the front-end single page web app. Works great!
avtar 10y ago
Django REST Framework can still play a part in the scenario you describe. Additionally I found this thread and the linked post really helpful in thinking about how Django and something like React can work together, with some more nuances and variation covered beyond just looking at one part being a SPA (handling routing, etc.) and the other a REST backend: https://www.reddit.com/r/django/comments/5sar7l/reconciling_djangos_templatebased_mvc_model_with/ https://www.reddit.com/r/django/comments/5sar7l/reconciling_...

wenbert 10y ago

Does Django have an equivalent for Laravel's Homestead?

collinmanderson 10y ago
One thing that's similar is https://github.com/django/django-box https://github.com/django/django-box. It's a Vagrant box primarily intended for developing Django itself. It includes Postgres, MySQL, Memcached, Sphinx, Pillow, selenium, and multiple versions of Python.
dguaraglia 10y ago
Not sure that's really necessary with Django. Lavarel, like most PHP frameworks, require an HTTP server configured with just the right version of PHP, etc. just for development. Django is much simpler: - django-admin startproject MyProject - cd MyProject - python manage.py migrate - python manage.py runserver That should give you a very decent development server without requiring VirtualBox or anything like that. I'd recommend following the official tutorial if you want to give it a spin.
- GoodbyeEarl 10y ago
  I've realized last week these simple steps to run a Django project, but, as I come from Node, I miss npm start.
  - StavrosK 10y ago
    What's the difference?
  - abdelhai 10y ago
    Why not use a Makefile or Invoke (written in Python) to achieve this?. That's what I have been doing.
- wenbert 10y ago
  I really think it needs it. Although "start project" works as it is, I can't be bothered installing MySQL and configuring nginx - that takes a bit of time especially if you miss something. There should be something like this for Django with all the "de facto" tech that a dev might need.

truetuna 10y ago

It's been a while since I've used Django but at the time (I think 1.6) I couldn't figure out a way to do a migration like adding a non null column to a decent sized relation 100M records without having the table lock up. I use flyway now for db migrations and what's great is that I can perform migrations in multiple steps (because it's just SQL). So in this case, I can alter table and add a column with nullable, deploy my app to write to both, migrate data at a later time, deploy app again to stop writing to the old column, update column constraints and remove old column. Does Django ORM have this kind of flexibility?

odonnellryan 10y ago
Yeah you can write raw SQL with Django ORM or in the migrations.

cutler 10y ago

Can someone explain the results of recent Techempower benchmarks (https://www.techempower.com/benchmarks/#section=data-r13 https://www.techempower.com/benchmarks/#section=data-r13) which show Django 22 times faster than Rails for JSON serialisation, 4 times faster for multiple queries, 7 times faster with fortunes and 23 times faster handling plain text? If these results were true wouldn't Django have replaced Rails long ago?

MaxfordAndSons 10y ago
Because if raw performance is your main selection criteria for a web framework you shouldn't be using either of them.

bachstelze 10y ago

Are there plans for django 2.0 to support asynchronous processing like in http://aiohttp.readthedocs.io/en/stable/ http://aiohttp.readthedocs.io/en/stable/ ? Everybody suggests celery as an asynchrone task queue, but i dont see how to resolve a http request with it. Will this come with python 3 because the async/await syntax introduced by PEP 492 is only valid for Python 3.5+ ?

fleetfox 10y ago
And why would you want it? What is your use case? Making something async introduces a lot of complexity with no obvious benefit. It's also not as simple as it looks. For instance all db access in django is synchronous at the moment and changing that is not trivial since it requires swapping out whole layer. I don't read the mailing lists but i'm not sure if it's even considered. If you want async requests today you can take a look at channels: http://channels.readthedocs.io/en/latest/ http://channels.readthedocs.io/en/latest/
- bachstelze 10y ago
  I want to return values from external REST APIs to the client. Is it really that hard with the new async/await syntax?