For someone completely new to Django I'd likely recommend Tango with Django or Hello Web App
I also grew up with Django... since 0.9 but didn't really focus on web development using Django, so for me I had to pick it up again from scratch and quick. Two Scoops is a reference book at best IMO. Use it if you are really comfortable with all the basics of Django and you have done at least 6-12 months of Django regularly.
Also, a shameless plug, I have built a website[2] where I collect the best webdev learning resources, you can find other good Django tutorials there. Funny enough, the website itself is built based on the stuff I've learned from the Django Unchained course =)
Besides that it looks really good!
Beats the cost of a coding academy and has let me go at my own pace.
I actually recommend youtube video tutorials! Like, some will show you how to make a basic photo hosting site... a blog site, etc. Follow those once or twice, and take it from there. Best of luck!
https://www.youtube.com/watch?v=oT1A1KKf0SI&list=PLxxA5z-8B2...
There is definitely a benefit to querying everything the same way if you can, so that way it's easy to grep where different tables are being accessed. Cuts down on bugs, security issues, etc.
Admittedly I rarely have to deal with the need for highly performant database code. But one could argue that performance problems are often better handled via caching or denormalisation (which really boil down to the same thing) than by clever work on the db side.
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)
models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3)
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.
https://docs.djangoproject.com/en/1.10/ref/models/querysets/...
You have to learn SQL to use the Django ORM anyways; it's required knowledge in order to be able to wield the higher level abstraction effectively. However, the way you write a lot of these things in SQL is substantially more verbose and harder to compose.
sounds like an SQL injection waiting to happen
You can just add various filter conditions to a dictionary, and then unpack them into the filter as kwargs. That way you can still build up the dictionary using if/else blocks or however you would normally build up a SQL query string.
SQL isn't scary, but for simple queries the Django ORM usually a lot more legible if you take the time to learn the DSL.
1: https://github.com/kennethreitz/records (same author as Requests)
You write your query as a string template, and then jinjasql interpolates the variables and provides the bind parameters. Makes it easy to maintain complex queries.
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.
- Long Term Support
- Last release to support Python 2
- Server side cursors for postgresI haven't looked at how it's implemented yet, but that sounds like a real godsend.
Very useful when you have an exotic templating engine for example and can't inherit the `registration/login.html` template
This should give a decent performance improvement for many websites.
I ask because I like the sound of the fulltext search mentioned in another comment, because it would mean I don't have to install a search engine to support that feature. So I'd switch to Postgres and start using Beta 1 pretty soon, if DRF will just-work with it.
Why don't you just try it?
But wait to deploy anything to production until DRF officially supports it (which should be pretty much at launch, DRF should be working with the beta now to ensure compatibility)
Really the most important part of this release, out of all.
This is the time where enterprise companies using Python and Django really need to switch to Python 3. In fact, anyone using Ubuntu 16.04 should already find themselves going "ugh" because they needed Python 2. More reasons to push forward.
It's reasonable that volunteer developers working on an open-source project sunset old versions, and old versions of language runtimes or dependencies. Nobody wants to keep maintaining 5-year-old versions with 12-year-old dependencies when they could use their time to improve the latest version instead.
Django is one of the most "responsible" projects in this regard - having LTS releases that are maintained for three years for free. Some projects even say "you should stick with github master" for fixes :)
But it's cool that Rails has a company providing paid enterprise support after the community support ends. Their pricing is surprisingly cheap - I would expect that if an enterprise has a legacy application that must be kept "stable" and never upgraded, then they would be willing to pay $10k and upwards per month for that privilege.
Django 1.6 (the last version to support Python 2.6) is still getting unofficial support: https://github.com/beanbaginc/django
https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/...
Whoosh is pure python and Haystack is a nice Django-like wrapper around search engines.
* whoosh.readthedocs.io
* haystacksearch.org