Meet the release of Django 1.6
Greetings, habralyudi. Yesterday, on the blog of the popular web framework for python, Django, there was news about the release of a new version under the number 1.6.
A complete list of all the innovations, as well as information on changes (including those that are backwards incompatible) 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 note the main, in my opinion, changes.
Work with transactions
In 1.6, a new API for working with transactions appeared. Starting with this version of the familiar to work with transactional functions
django.db.transactionis now considered obsolete and will remain for compatibility to 1.8. To replace them comes
The basic logic here is approximately the following: earlier, the key point was the behavior control mechanism when working with a transaction commit - autocommit (i.e., each SQL query starts a transaction and commits it automatically) or manual commit (the
COMMIT;SQL query is sent independently). This mechanism worked pretty 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 blocks nested in one another
commit_on_success(), then a situation may arise that the result of the execution of the internal block will be commomited, breaking, from the point of view of transactions, the atomicity of the external block.
What will happen now: firstly, the junga now by default turns on the auto commit mode, it is worth noting, violating PEP 249 . And secondly, the only mechanism for working with transactions is
atomic()that it is not afraid of nesting, because in the case of an external block, it works with a transaction, and in the case of a nested block, with SQL storage points . Also now,
TransactionMiddlewarea configuration constant is available instead
ATOMIC_REQUESTS, when setting the value to
True(default value -
False), the django will try to process one HTTP request in one transaction. Those. the request was executed without any problems - committed, no - rolled back.
It should be noted that
atomic()both a decorator and a context manager can be used:
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 is, as always, available in the documentation .
Permanent database connections
This, of course, is not a connection pool, because they are isolated by the threads in which the application is running. But, this is already much better, in terms of performance, than a constant connection to the database with every HTTP request. The lifetime of the connections is controlled by the configuration constant
In 1.6, a new test runner appeared
django.test.runner.DiscoverRunnerthat uses the logic to search for modules with tests from
unittest2. Now tests can be located in any modules if the name of the file containing them matches the mask
However, at the same time, tests from
tests/__init__.pywere found, and, accordingly, will not be launched (unlike the behavior in previous versions). The easiest solution is to rename them to something of the form
tests/test.py. And also, the docs will no longer be loaded automatically. But it will not be difficult to turn them back on, following the directions from the documentation for
By the way, the management team
./manage.py testnow has an option
--pattern, specifying which, as you might guess, you can change the mask to search for files with tests.
Management team check
django-admin.py checknow allows you to check the compatibility of the project or application with the current version of the jungle, giving alerts in case of finding incompatible places. It is assumed that this command will help in the transition to new versions of the framework.
By the way, 1.6 is the latest release of the jungle, which still supports python version 2.6. Starting with the next release, at least 2.7 python will be required.
QuerySetsupports syntactic sugar, in the form of methods
last(), and also
earliest()in addition to
ORM now supports
secondin addition to those added earlier
daywhen searching through fields with a date and / or time.
Well, the traditional survey. Interested in the percentage ratio, so if several versions are used, it makes sense to indicate the one on which the main development is being conducted.
Only registered users can participate in the survey. Please come in.
What is your production version of Django?
- 13.5% > = 1.6 80
- 55.8% 1.5 329
- 23.4% 1.4 138
- 4.7% 1.3 28
- 0.5% 1.2 3
- 1.8% <= 1.1 11