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 autocommit(), commit_on_success()and commit_manually()the module django.db.transactionis now considered obsolete and will remain for compatibility to 1.8. To replace them comes atomic().

    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 anothercommit_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
    # декоратор
    def viewfunc1(request):
        # этот код будет выполнен внутри транзакции
    and as a context manager:
    # менеджер контекста
    def viewfunc2(request):
        # этот код выполняется в режиме автокоммита
        with transaction.atomic():
            # а здесь уже выполняется внутри транзакции

    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 CONN_MAX_AGE.


    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 test*.py.

    However, at the same time, tests from models.pyand 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 test_models.pyand tests/ 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 unittest.

    By the way, the management team ./ 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

    The team 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.

    ORM Improvements

    Now QuerySetsupports syntactic sugar, in the form of methods first()and last(), and also earliest()in addition to latest().

    ORM now supports hour, minuteand secondin addition to those added earlier year, monthand 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

    Also popular now: