Live data from Hacker News

Django 1.10 released

djangoproject.com

81–90 of 122 posts

Re: Django 1.10 released

#81
post #71
post #67

Earlier quoted context omitted.

That is true, but it was fixed in Django 1.4... in 2012. Technology moves a bit in 4 years.

Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views). Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any…

SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction.

A GSOC project is currently adding customisable indexes: https://groups.google.com/forum/#!topic/django-developers/XA...

Re: Django 1.10 released

#82
post #27

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suc…

Channels will get there. It just wasn't quite ready on time for 1.10. Hopefully it will be ready on time for 1.11, and then it'll ship in Django.

I just used Channels in a personal project and it's great! My requirements were mostly basic and I haven't put it into production yet, but everything has gone smoothly so far.

Re: Django 1.10 released

#83
post #63

Earlier quoted context omitted.

Sure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.

There are two benefits to having subpackages in the way you describe. The first, as you mention, is to slim down the framework. I don't think this gains a whole lot except for trimming down deployment sizes. If you don't use the components then the code doesn't run. The other benefit would be so that the components could be used outside of Django. Using forms or templates might appeal to projects outside of Django. T…

DJango 1.10 source download is 7MB.

I don't know what is normal for Ruby. Basic crud app in Java tends to be 20-50MB, but DJango above doesn't have DB drivers or anything yet so I suspect it is similar.

*seems reasonable.

Re: Django 1.10 released

#84
If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?

Re: Django 1.10 released

#85
post #76

Earlier quoted context omitted.

sibling mentioned ORM migrations not being built in. It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily. The core has also been majorly rewritten, which has made entire classes of b…

> The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.

Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals.

I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning.

[0]: https://code.djangoproject.com/ticket/24386

Re: Django 1.10 released

#86

If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?

If you are going to be around and have time to actively upgrade the project every time a new release comes out until it's running on the next version of LTS, I'd choose 1.10.

If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.

Re: Django 1.10 released

#87

If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?

If you are going to be around and have time to actively upgrade the project every time a new release comes out until it's running on the next version of LTS, I'd choose 1.10. If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.

Thanks. It's not so much that we don't work on it, just that we work on product improvements that move the dial more than django upgrades. But you certainly accrue tech debt to do so.

Re: Django 1.10 released

#88
post #73
post #3

I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.

It is quite scary for me to read that people have serious issues upgrading their frameworks, wouldn't it be better to use pyramid (or flask eventually) instead? It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready. You will not get things like admin panel as a dow…

You get similar issues with libraries that you use for flask or pyramid too though, if you don't upgrade it for 4 years.

Re: Django 1.10 released

#89
post #85

Earlier quoted context omitted.

> The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare. Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.

Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals. I did report…

Exclude filters are awful and very unintuitive if you know SQL in my experience. I'd much prefer to use negated filters like: `.filter(id__notequal=3)`. I'm giving a talk at djangocon AU in a couple of weeks where I'll step through examples like this.

Re: Django 1.10 released

#90

If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?

The next LTS will be released in about 9 months. If you're willing to make a small upgrade at that time, I'd build on 1.10 and then upgrade to 1.11 LTS, which will give you 3 years (I think..) plus 9 months of 1.10 support.

Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. The new release scheme means that if you're running on an LTS with no deprecation warnings, then you should be able to upgrade to the next LTS release with no changes (but lots of new deprecation warnings).

Hope that helps.

https://docs.djangoproject.com/es/1.9/internals/release-proc...

Post reply on HN