Meet the release of Django 1.6

Greetings, habra people. Yesterday, the blog of the popular Python web framework, Django, had the news about the release of the new version numbered 1.6.

A complete list of all the innovations, as well as information about changes (including backward incompatible ones) is traditionally found in the release notes . According to my feelings, this time the developers focused more on working with the database.
')
In this news article, I would like to point out major, in my opinion, changes.

Work with transactions

In 1.6, a new transaction API appeared. Starting with this version, the autocommit() , commit_on_success() and commit_manually() functions familiar to working with transactions from the django.db.transaction module django.db.transaction now considered obsolete and will remain up to 1.8 compatible. atomic() comes to replace them.

The basic logic here is approximately the following: earlier, the key point was the behavior control mechanism when working with a transaction commit — an autocommit (that is, each SQL query starts a transaction and commits it automatically) or a manual commit ( COMMIT; SQL query is sent independently). This mechanism worked quite well in the case of independent transactions, but in the case of nested use of obsolete functions, the result could be incorrect. For example, if we have two commit_on_success() blocks nested inside one another, then a situation may arise that the result of executing the internal block will be commited, having broken, from the transaction point of view, the atomicity of the external block.

What will happen now: first, janga now includes auto-commit mode by default, it's worth noting, breaking the PEP 249 . And secondly, the only mechanism for working with transactions becomes atomic() , which is not afraid of nesting, since in the case of an external block, it works with a transaction, and in the case of a nested block, it works with SQL save points . Also, instead of TransactionMiddleware , the configuration constant ATOMIC_REQUESTS , when setting its value to True (the default value is False ), the django will try to process one HTTP request in one transaction. Those. request executed without any problems - commited, no - rolled back.

It should be noted that atomic() can be used as a decorator as well as a context manager:

 from django.db import transaction #  @transaction.atomic def viewfunc1(request): #       do_stuff() and as a context manager: #   def viewfunc2(request): #       do_stuff() with transaction.atomic(): #       do_more_stuff() 

A more detailed description - as always, is available in the documentation .

Persistent database connections

This, of course, is not a pool of compounds, since they are isolated by the threads in which the application is running. But, it is already much better, in terms of performance, than a constant connection to the database with each HTTP request. The lifetime of connections is governed by the configuration constant CONN_MAX_AGE .

Tests

In 1.6, a new test django.test.runner.DiscoverRunner , which uses the logic of finding modules with tests from unittest2 . Now tests can be located in any modules, if the name of the file containing them matches the test*.py mask.

However, at the same time, tests from models.py and tests/__init__.py are found, and accordingly, they will not be run (unlike the behavior in previous versions). The easiest solution is to rename them to something like test_models.py and tests/test.py And also, doctoral tests will no longer be loaded automatically. But they will not be difficult to turn back, following the instructions in the unittest documentation.

By the way, the management team ./manage.py test now has the option --pattern , indicating that, as it is not difficult to guess, you can change the mask to search for files with tests.

Management check command

The django-admin.py check command now allows you to check the compatibility of a project or application with the current version of the jungle, issuing alerts in case of incompatible locations. It is assumed that this command will assist in the transition to new versions of the framework.

By the way, 1.6 is the latest jungle release, which still supports python version 2.6. From the next release, a minimum of 2.7 python will be required.

ORM improvements

Now QuerySet supports syntactic sugar, in the form of the first() and last() methods, and earliest() in addition to the latest() method.

ORM now supports hour , minute and second in addition to the previously added year , month and day when searching for fields with a date and / or time.

Well, the traditional survey. Interested in the percentage, so if you use multiple versions - it makes sense to specify the one on which the main development is conducted.