Live data from Hacker News

Django 1.11 beta 1 released

djangoproject.com

11–20 of 87 posts

Re: Django 1.11 beta 1 released

#11
post #3

Release notes with the new features in 1.11: https://docs.djangoproject.com/en/dev/releases/1.11/ Highlights: - better support for creating indexes on your Models with class-based indexes - widget rendering in forms now uses the templating system instead of python - Explicit subquery expression support via Subquery and Exists expressions.

widget rendering in forms now uses the templating system instead of python

I haven't looked at how it's implemented yet, but that sounds like a real godsend.

Re: Django 1.11 beta 1 released

#12
post #3

Release notes with the new features in 1.11: https://docs.djangoproject.com/en/dev/releases/1.11/ Highlights: - better support for creating indexes on your Models with class-based indexes - widget rendering in forms now uses the templating system instead of python - Explicit subquery expression support via Subquery and Exists expressions.

widget rendering in forms now uses the templating system instead of python I haven't looked at how it's implemented yet, but that sounds like a real godsend.

There's now a get_context() method which returns a dict of useful info. the render() method takes that and applies it to widget.template_name.

Re: Django 1.11 beta 1 released

#13
post #4
post #2

Subquery expressions looks like it would be just easier to write SQL, instead of going through the Django ORM. This is where SQL starts to show its expressive strength over ORMs.

You're right, except for when you need to support multiple database backends. For projects it's usually not a concern, but for libraries it certainly is. The ORM has been slowly adding more and more complex types (Expressions) for more complex use cases, which can be mostly ignored for regular CRUD apps.

Aren't SQL subqueries pretty much standard across all databases anyways? Why would writing them in Django's ORM be more compatible?

Re: Django 1.11 beta 1 released

#14
post #2

Subquery expressions looks like it would be just easier to write SQL, instead of going through the Django ORM. This is where SQL starts to show its expressive strength over ORMs.

Absolutely. The amount of "magic" Django does slowly became a real detractor for me. The way I define queries by using a custom language in the form of keyword arguments makes me wonder why I don't just learn SQL instead? I would much rather do something like: models.Foo.objects.filter(sql=my_sql_query_str) Instead of something like: models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3) And no special…

> Just a string of SQL that I compose with Python string formatting

sounds like an SQL injection waiting to happen

Re: Django 1.11 beta 1 released

#15
post #4

Earlier quoted context omitted.

You're right, except for when you need to support multiple database backends. For projects it's usually not a concern, but for libraries it certainly is. The ORM has been slowly adding more and more complex types (Expressions) for more complex use cases, which can be mostly ignored for regular CRUD apps.

Aren't SQL subqueries pretty much standard across all databases anyways? Why would writing them in Django's ORM be more compatible?

Field names, table names, quotes or not - a few examples of things that can differ. The syntax of subqueries themselves are standard AFAIK.

Building subqueries inside Django gives the rest of Django access to them for things like aggregation or filters.

Re: Django 1.11 beta 1 released

#16
post #2

Subquery expressions looks like it would be just easier to write SQL, instead of going through the Django ORM. This is where SQL starts to show its expressive strength over ORMs.

Absolutely. The amount of "magic" Django does slowly became a real detractor for me. The way I define queries by using a custom language in the form of keyword arguments makes me wonder why I don't just learn SQL instead? I would much rather do something like: models.Foo.objects.filter(sql=my_sql_query_str) Instead of something like: models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3) And no special…

Yep. I'm wondering if a framework would ever adopt something like Records [1].

1: https://github.com/kennethreitz/records (same author as Requests)

Re: Django 1.11 beta 1 released

#17

Earlier quoted context omitted.

Absolutely. The amount of "magic" Django does slowly became a real detractor for me. The way I define queries by using a custom language in the form of keyword arguments makes me wonder why I don't just learn SQL instead? I would much rather do something like: models.Foo.objects.filter(sql=my_sql_query_str) Instead of something like: models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3) And no special…

https://docs.djangoproject.com/en/1.10/topics/db/sql/#django... you can already do this. the django ORM has a convenient and expressive API for a lot of very common types of queries, but lets you easily drop back into raw SQL when you have a high complexity query that you want to write by hand.

Raw requires a primary key to be returned so it can rebuild the model object for you. You could also use django.db.connection.cursor() directly.

Re: Django 1.11 beta 1 released

#18
This is a bit off topic, but can anyone suggest a decent Django tutorial? I've just recently learned python, and would like to build a few projects using Django. I completed Django's official tutorial[1], but when it came time for me to actually start building something, I found I didn't really understand what was going on. I should mention I'm inexperienced in both web application development and python in general.

1: https://docs.djangoproject.com/en/1.10/intro/tutorial01/

Re: Django 1.11 beta 1 released

#19
post #18

This is a bit off topic, but can anyone suggest a decent Django tutorial? I've just recently learned python, and would like to build a few projects using Django. I completed Django's official tutorial[1], but when it came time for me to actually start building something, I found I didn't really understand what was going on. I should mention I'm inexperienced in both web application development and python in general.…

A bit of googling and you will find many excellent resources - filter on 'last year' in the search results. One recommended book is 'two scoops of Django'. You should get familiar with the request response cycle (Language agnostic) and that will make things a lot clearer as you build up your skills.

Re: Django 1.11 beta 1 released

#20
post #10

my favorite feature so far is search, this is first LTS release with search support builtin (was introduced in 1.10) https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/...

Rather looking forward to this. Got a number of use cases that don't justify using a 'proper' search engine but would really benefit from a more flexible search than an icontains filter.
Post reply on HN