Hacker News new | past | comments | ask | show | jobs | submit login
Django 1.11 Released (djangoproject.com)
348 points by andrewingram on Apr 4, 2017 | hide | past | web | favorite | 141 comments



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


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

This is the same problem I have with most ORM's as well: the easy stuff is easy, and the hard stuff is harder than just doing your own thing (using SQL directly). My solution to this ORM problem and the admin situation is the same: use admin (and ORM) for doing easy things, and don't use it for hard things. It works well!

I've seen a lot of Django codebases where they try to build the whole app around the admin interface, and it's way more trouble than it's worth. Reasonable people could disagree about this, but my stance is to use it for the easy goodness it provides, but get away from it when it starts getting in the way.


> use admin (and ORM) for doing easy things, and don't use it for hard things. It works well!

With the ORM though there is usually a good reason for why the hard things are hard, and writing your own SQL where needed adds very little friction.

With the admin adding a button to kick off some task should be trivially easy, but for whatever reason involves either using all sorts of terrible hacks that make the codebase completely unreadable, or else creating an entire second admin. That doesn't feel right.


Yeah adding buttons to the top of a detail page, or a second form page for an admin action are unnecessarily hard. I've had to do both a number of times in the last few months, and referring back to an existing implementation is the only way I remember how to do it.

Those two particular customisations should be a lot easier to do, and it might even be something I'll look to implement as a 3rd party library or directly within Django.


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/#dj...


Yeah this is the best native workaround I'm aware of.


Is it really a workaround, if it's already baked in as a feature though?


Yes, in 2017 it's a workaround. The 2010-onwards way to solve this problem is with a client-side filter in the select input, so that you don't need to open a new window.


I think the Admin is great. Even of you aren't planning to use it in your production app, it makes many development tasks so much easier. It is a great way to create, view and filter your data during development and when you need something new its usually just a line or two of code. It is staring to look a bit dated with the widgets though.


There was a discussion a few years ago about revamping/updating the Django Admin - but I don't think it got much traction:

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

My understanding is it's not something they care enough about yet to fix - or it's too hard/expensive.

UPDATE: Also found this blog post from one of the core devs/founders:

https://jacobian.org/writing/so-you-want-a-new-admin/


> The admin may look simple on the surface, but it’s shockingly complex and represents a ton of work.

This matches my experience. I can't escape the feeling that 90% of that complexity is irrelevant at best, and counterproductive at worst, for my current use-case -- but I haven't quite mustered the bravery to write my own custom admin site for my app.

I wonder if DRF's CoreAPI schemas would make this easier, since you can now auto-generate a JS client for your API models, so you just need to wire up routers and views for your CRUD.


It's not. Every template, every view, every form can be overriden. And all of them have hooks on the admin config class to handle simple customization. The software internal is quite amazing and uses all Django's features in the book.


> uses all Django's features in the book.

Also, I think the admin traditionally has been a good driving force for feature improvement.


IMO, the proper method here is a frog boiling approach. Throwing it out and starting all over is bound to introduce regressions and even new user facing bugs. So we shouldn't of "steady, incremental improvement" as settling. But we could probably use more of those steady incremental improvements.


I personally agree: focus on the most important things, fix those, then move on to the next thing.


I agree that Django's admin interface isn't perfect. However, it's only there to get you started - as you say, it's flexible and generic.

If you have a complicated application then you should be building your own admin interface, with specialised workflows that make it easy for your (admin) users to enter and manipulate the data you wish to manage.


The problem is that it's not really flexible in its default state.

If you want to add a custom action to the instance view of one of your models you have to:

- write a view for your custom action

- override the generated urls for the model admin

- override the template(???) for the admin instance view to show the action

Considering the Admin itself already has the styling in place to add more custom actions, the main issue is that no one has put in place enough infrastructure to make this easier for people.

(Internally we've written a couple helpers for this, though our way of doing thing relies on internal patterns so might not be great for Django itself)


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


At my current place of employment, we modified and extended Django Admin with the Suit[0] theme to become what was basically a CRM that drove the sales and administration of a business with >$1 million revenue.

Eventually we built an actual operations/management/sales interface because Django's admin had too much extra stuff and lacked certain things we wanted to implement, but it wasn't that difficult to put together and it worked well for several months.

[0] http://djangosuit.com/


Similarly, I helped build Student database and CRM for a family of 3 schools totaling ~7M revenue. It's built mostly on top of the admin (with a custom theme).


My experience is that the vast majority of things are out there in the docs, however it does so many things that it takes time to understand it in sufficient depth so as to make significant changes.

The admin is easy; but it's not simple. Behind the simple UI there's a lot of work going on, and a lot of is so that the simple customizations most people work can be done trivially.

Have no shame in making your own templates and views within the admin. That's why it provides those escape hatches.


As soon as you find yourself hacking the admin template to place a button, you should strongly consider ditching the admin interface and rolling your own views.

Django admin is easy to get started with, but a huge pain to extend.


Admin actions work well for many tasks. Or a link styled as a button is easy enough to add, though you will need view to process it.


May be coz it's not meant to be very customizable? When you start overriding methods, it's better to use a regular view.

I've always seen the admin as a sort of phpmyadmin. For doing very basic crud.


You can do some pretty complex stuff with it when you understand how Django''s forms and other parts work.


> I fear the admin site code has become so flexible and generic that it's difficult to extend, which is discouraging improvements.

It's doable. One of the former companies I worked for used to run its entire lead-management-based system on top of a modified 0.96 Django admin, that was ~10 years ago (said company was a mortgage broker). Monkey-patching is a hell of a drug. I'm pretty sure things are way easier to extend now.


Well, it isn't much of a problem, All you need is to use `django-ajax-selects`, and you can make all the fields with foreignKey into ajax loading like select2. If that's your biggest gripe with admin, then here is an easy solution for that.

In Django, you need to explicitly do some things and that's okay.


Admin is an app written in Django. Don't see how evaluating admin app applies to evaluating Django.


I simply add my own admin code separately and add links to the default admin interface to my views.


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


Damn, those are new ? Or did just the formating change?


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.


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.


Is there anywhere django docs on how to actually use the brin/gin indexes? All I can find is that they exist...



single field?

what about `unique_together` and `index_together`?


You previously couldn't define the name or type of an index. You just listed tuples of fields to be indexed.


Class-based db indexes are new.


hm. 'indexes' will bother me. I've lived with 'color' vs 'colour' for a long time, perhaps I'll be ok.


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


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?


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


What is your main stack?


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


> 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 only started using Django about 6 months ago, but I would have started much earlier if I'd known about the incredible built-in admin interface. The built-in user system is also very convenient. I think Django makes a great backend-only system, especially in combination with Django REST framework.


2.0 is just a time-based version numbering change. Besides dropping Python 2 support, 1.11 -> 2.0 will not be any more of a break compared to 1.8 -> 1.9.

If your code works on 1.11 without warnings, it will work on 2.0 just fine.


> Besides dropping Python 2 support

"Apart from that Mrs Lincoln, how did you enjoy the play?"


Have a look at Django Rest Framework for your backend. Also there are lots of other Django apps which might be useful for backend only apps like eg. ratelimiting.


If you're looking for a good ORM with migrations in python, I highly recommend SQLAlchemy and Alembic, with the web app in Flask (although you could use any web framework, which is a nice benefit of using smaller components like this). There's a bit more boilerplate to get it set up the first time vs Django, but it's not bad and there are good resources for it. SQLalchemy is an amazing ORM, and the flexibility of being able to write and organize your code with this stack in ways that work well for your problem vs being stuck doing it the "Big MVC Framework Way" in Django is really nice.


You might want to look into Django Rest Framework [1]. It is very well made and documented. Django's ORM + DRF is a great combination for API servers.

[1] http://www.django-rest-framework.org/


> 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?

Yes, he is right. If you add The rest framework: http://www.django-rest-framework.org/ you can implement your app all the newest JS frameworks and maintaining a great server environment. You'll have nice debugging tools, a great language and a robust and mature framework.


I use it all the time for small data migration projects, as the ORM saves a lot of time for inserts and updates. The Admin makes it very fast to create, edit and view data as well. Even if you don't use Django at all for the final project, it can save a lot of effort during development.


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


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


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.


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.


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


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/MTvOPDNQXL...

Here's the final summary: 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.


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


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.


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


If you require longer support, you probably want to pay for such a thing. Does RHEL package django?


It's in EPEL.

Also, Django 1.11 will likely be in Ubuntu 18.04, supported until 2023.


How many crash bugs make it past 8 months? Usually you find those out fairly quick.


Do you stop working on your django 1.11 -based app after 8 months? What it you find a novel use for a newly introduced feature two years from now that crashes?


I personally upgrade to follow the latest release. But if I were on a LTS... I wouldn't use that unstable feature.


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


Django has advanced significantly over the last five years. It's definitely worth a look if you haven't tried it in a while. A few things to start with:

- http://www.django-rest-framework.org/

- https://channels.readthedocs.io/en/stable/

- https://docs.djangoproject.com/en/1.11/topics/signals/


I didn't know about channels! It looks great


I recently posted about why I dislike Rails. For a long time, I also disliked Django, for somewhat similar reasons. [0]

The biggest thing that I disliked about Django was its templating system. Its attempts to magically render values were (and are) offensive. When I looked before, just like Rails, it was take it or leave it, and there was little sympathy for making it pluggable.

Such issues, and the culture's Rails-like resistance to outside suggestion and interoperability, pushed me into Pylons/Pyramid.

Today, I think Django has improved a lot, and I don't think it's fair to continue to lay the pox of being "Rails-for-Python" on it.

Django now supports third-party templating engines (so the dealkiller is gone) and last I checked, the SQLAlchemy integration, while not official, is much better. They now have Python 3 support and as pointed out here, will be going Python 3 exclusive soon.

I've submitted a few bugs and they get triaged quickly. I had a patch or two merged. Pretty happy with that. The Mezzanine guy is also great about this stuff.

Django does follow the old-school big magic model, but I haven't encountered much [recent] trouble in working around that. The community does not seem to respond negatively to such suggestions anymore.

People say it comes down to Ruby v. Python, and I think that's true, but in a different way than most. It comes down to the core culture of Ruby v. Python.

As the MVC framework hype and subsequent noob-influx died down, Django was left with the core Python community of mature hackers who've developed a refined palette for simplicity. This has been Django's biggest asset, and has turned it into something that's worth using today.

Disclaimer here: I was not then, and I am not now, super deeply involved in Django, either the product or the community. This is primarily based on my impressions from light observation and use. Some/much of it could be wrong.

[0] https://news.ycombinator.com/item?id=14015270


I'm using Pyramid on a daily basis. I'm very happy with how everything performs. Things never get in my way and SQLAlchemy is awesome ORM solution. For me pyramid is the sweet spot between microframeworks and django.

The team that manages Pyramid is extremely competant, I've updated my applications over multiple releases without issues over the years.

I think what people use often depends on weather you prefer to have choices being made for you with tightly coupled systems vs sane defaults that you can customize to your liking.


> The biggest thing that I disliked about Django was its templating system. Its attempts to magically render values were (and are) offensive. When I looked before, just like Rails, it was take it or leave it, and there was little sympathy for making it pluggable.

Templating is the most frequently subbed out part of Django. I'm not sure how you'd make it more "pluggable."


They made it so that you could still use django's "render helpers" and things like the middleware directly, and just replace the 'render the template file' part.

Before you could always call a third-party rendering library, but it usually meant you wouldn't get things like the Django context renderers or template file lookup by default


Mostly Ruby vs Python, though I think that's a big distinction. Rails is Ruby's killer app, but Python has killer apps in many things, so if you want to integrate something else (like Machine Learning for example) easily into your code, then Django (because it is Python which has a lot better support for ML) makes that so much easier.


Documentation! I think Django's are more clear and easy to navigate:

https://docs.djangoproject.com/en/1.11/

vs

http://guides.rubyonrails.org/

Also looking at the footer of each site, the Django one screams 'inclusive community' which I think is a positive signal in terms of its future growth.


Mostly a Python vs Ruby thing. Both are pretty mature frameworks of roughly the same age, so for the most common use cases it doesn't make a ton of difference.

Personally, as a heavy Python user, I prefer Django's explicitness vs Rails more "magic" style.


This will likely be controversial, but IMO both frameworks will "go wrong by default" if your codebase/feature set/team working on it start to get large, and rails is worse. There is no real modularity of features or services encouraged, you by default just have a big bag of models with all sorts of implicit couplings because they're all hooking into each other's public ORM methods and lifecycle hooks and it becomes a nightmare.

By using lighter weight frameworks you're forced to build parts of your own framework in some ways, which can be a bit more work in the short term, but that means it can be optimized for your domain and you can do more to set up explicit boundaries/document how the team should use things. You can also do this in rails/Django, but then you start ignoring the built-in stuff that made them popular in the first place, and there is such a strong idea of "the rails way" that it'll be hard to get buy-in to diverging from that.

OTOH if you're building something that has a pretty moderate scope and aren't worried about it getting too big, both will get the job done fine.

As additional points, rails is also quite a bit slower, and python is honestly a more versatile language than ruby these days (if you want to pull in any ML or scipy code there are obviously a lot more python options).


> There is no real modularity of features or services encouraged...

I've used multiple apps per Django project for grouping and isolating features. The Two Scoops book lays out a nice project architecture for doing this, and some people take it as far as to deploy separate Django apps within the same project as separate services.


Yeah it's certainly possible, in both Django and Rails. But I'd still argue that both frameworks lead you astray by default unless you consciously go against the grain to avoid it.


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.


Does Rails have anything like the django admin?


No idea if this is comparable: https://activeadmin.info/

Edit: What a long strange trip it's been. According to my old bookmarks, wycats developed a rails admin module about 10 years ago (code not available today). I discovered that he also worked on Merb, sort of a fork of Rails, and then after helping to merge that back into Rails, he helped sferik port MerbAdmin to RailsAdmin, which exists today!

https://github.com/sferik/rails_admin

I will definitely have to try Rails 5 and see what's up, it looks like I missed a lot over the years.


Just a heads up: Admin gems are only suitable for projects that are simple and stay simple. If you want to do something that's not provided by your admin gem, you'll be fighting it. I have gone through that arduous path myself multiple times, only to end up rewriting everything from scratch.

I would love to know if Django's Admin fares better in this regard.

More: http://rubyjunky.com/get-rid-of-your-admin-gem.html


I've used the Django admin in pretty much every production project I've touched. It's the bees' knees. There's some customization overhead that becomes higher than doing your own thing is you really want to make your own admin views, but at that point nobody's stopping you from making dashboards from scratch.


I came to a similar conclusion in Django. I now build my own admin interfaces.


Not built in but it's really easy to build it yourself or use a Gem like ActiveAdmin.


As someone who hasn't used RoR, can you talk about the difference in asset handling?


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.


This is the same in Python, with a bunch of different options. A common one is webassets[1] which has simple integrations for django.

[1]: https://webassets.readthedocs.io/en/latest/


It's also possible to use Webpack with Django easily. With working hot module reload and everything. https://github.com/owais/django-webpack-loader


For a similar experience in Django, one should better start with https://github.com/pydanny/cookiecutter-django instead of the default generated project.


> (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/


Philosophy.

Rails' philosophy is "convention over configuration", which means there's a lot of what might be called "magic" and it's less clear how to override defaults.

Django adheres to a more "pythonic" approach in which transparency is valued and it's better to be explicit than implicit. More things are documented and configurable.

While Django does have a certain way it expects you to do things (especially in the sense of where boundaries lie between modules), I find that that's at a higher level of abstraction than Rails, where convention rules down to the level of URL structure.


That depends on many factors, and without specifics nobody is going to be able to provide anything objective.


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.


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.


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


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.



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


I'd highly, highly recommend Django REST Framework: http://www.django-rest-framework.org/

It's built on top of Django, and makes creating APIs super easy.


Ok, I'm actually looking at that for the last few days, but would make the same question replacing Django with DRF.


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.


Another bit of "FUD" I have is that I always consider the database (pgsql say) to be the one thing that won't change, so I create tables in SQL and would keep that even if the service changed from say Python to Go.

With Django, would I be able and would it make sense to keep the SQL schema if I changed languages?


I've not used SQLAlchemy much, but I assume it can be configured to map onto the DB tables that Django has created.

Django has the concept of `apps`, where each app gets its own namespace. So for model `foo` in app `app1`, you get a table `app1_foo`. Inside that table it's just the standard SQL columns that you'd expect. So you might need to override the default table name if your new ORM provides one, but no more than that.

The only other piece that might give you grief is the ContentType machinery; there's a content_type table that has a row for each model class, which lets you do generic foreign key lookups. It might be some work to duplicate that, if you start depending on it. But it's not super-complex; it's just <id, app_label, model> in that table.


Thanks - yes, I'll have to try and see. In the moment I can only model stuff in terms of SQL, which I like, but becomes tedious typing almost the same query in 50 places...

(My last API was in Go and felt like too much work, even though it worked nicely in the end.)


I'd like to second what the poster above said. My main stack is flask and in my most recent project I decided to use DRF since I was working with a pretty simple data model. It was stunning how much faster it is to go from nothing -> v0 vs building in flask.


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


Depends on what you're doing. For API stuff, my team's had great luck with Flask + Flask-RESTful:

- We prefer SQLAlchemy to Django's ORM. - We don't need any templating since we're always returning JSON. - Django is more of a framework: you plug your code into the appropriate spots. Flask is more of an API: you call it from your own code. - Django is brilliant... up until the point you want to do something non-Django-y and have to work around a few layers of magic.

I have nothing bad to say about Django and happily use it where it's appropriate. It's not one-size-fits-all, though, and in my experience there are better solutions to some non-HTML-web stuff.


I wanted to try Flask but it didn't have Python3 support when I looked into it.

Django+Django Rest Framework are awesome. We do actually use templates for some emails so it's one of the times where it's nice that the template system was ready to go even though the rest of the site is just json.


Flask has supported Python 3 for many years.

Some practical improvements in the 3.x line came from the heavy but constructive criticism that Armin Ronacher gave while ensuring that Flask supported Python 3.


We run flask in production with Python 3.6


Yes, definitely! You can use something like https://github.com/mbylstra/django-wham to consume APIs using the same interface.


Thanks - this is a great little idea. Unfortunately no commit in 3 years, but there should be something similar being developed.


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?


Yeah you can write raw SQL with Django ORM or in the migrations.


Can someone explain the results of recent Techempower benchmarks (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?


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


Are there plans for django 2.0 to support asynchronous processing like in 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+ ?


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/


I want to return values from external REST APIs to the client. Is it really that hard with the new async/await syntax?


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


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


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!


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


Does Django have an equivalent for Laravel's Homestead?


One thing that's similar is 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.


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.


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.


You don't use nginx in dev.


I do. with very similar configuration to production


Why? Not that hard to set up but seems overkill.


I've realized last week these simple steps to run a Django project, but, as I come from Node, I miss npm start.


Why not use a Makefile or Invoke (written in Python) to achieve this?. That's what I have been doing.


What's the difference?


It's not terribly difficult to roll one's own using Vagrant and Ansible. We maintain a project template for this in a git repository, where playbook resources are shared between development and deployment. Other than paths and which configs in Django are used, this makes development and depolyment nearly identical. It also makes spinning up a new project trivial. Just a couple commands.


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/

[1] https://docs.djangoproject.com/en/1.11/releases/1.11/#querys...

[2] https://alexcbecker.net/blog.html#django-is-terrible


[2] is nothing but a troll.

The statement: "too many footguns to be used for important projects" is so obviously ridiculous it isn't worthy of a rebuttal.


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


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.


Django is not "terrible" Jesus Christ what an annoying title




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: