ФорумПрограммированиеPythonDjango → Django и особенности использования транзакций в MySQL

Django и особенности использования транзакций в MySQL

  • adw0rd

    Сообщения: 22905 Репутация: N Группа: в ухо

    Spritz 24 мая 2012 г. 12:51



    Вкратце:

    MySQLdb использует AUTOCOMMIT=0
    То есть каждая операция изменения данных должна завершаться COMMIT/ROLLBACK для фиксации или отката изменений. Если вы раньше использовали расширения PHP (PDO, Mysqli) или Ruby для доступа к MySQL, то наверное будете немного удивлены, поскольку практически во всех драйверах доступа к БД при подключении значение AUTOCOMMIT не меняется (а по умолчанию в MySQL оно задано как AUTOCOMMIT=1).


    MySQL по умолчанию использует уровень изоляции транзакций REPEATABLE-READ
    А в PosgreSQL или Oracle используется по умолчанию READ-COMMITTED.

    На практике это означает, что две разные транзакции не знают что происходит с данными которые изменила (COMMIT) одна из транзакций. Смотрите пример.


    Пути решения проблемы:

    Добавить в my.cnf:
    transaction-isolation = READ-COMMITTED


    или в settings.py:
    DATABASE_OPTIONS = {
    "init_command": "SET storage_engine=INNODB, SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED",
    }




    Как это проявляется на практике читайте в оригинальной статье:
    http://habrahabr.ru/post/144161/
    adw/0
  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 24 мая 2012 г. 19:40, спустя 6 часов 48 минут 50 секунд

    Насколько повсеместно используется MySQL вместе с Django? Так же как и PHP + MySQL или всё же нет?
    Спустя 123 сек.
    Вот кстати MySQL-python для windows, вдруг кто-то будет искать, а то я сначала ввел pip install MySQL-python и пытался понять что там за ошибки с реестром
    http://www.codegood.com/archives/129
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 25 мая 2012 г. 5:41, спустя 10 часов 40 секунд


    Насколько повсеместно используется MySQL вместе с Django? Так же как и PHP + MySQL или всё же нет?


    Джангисты чаще - это подросшие пхписты. Поэтому берут, то что умеют лучше готовить.
    Бывают ещё случаи, аля - ну тут прошлая команда делала на php+mysql, но чего-то мы потом подумали быть в тренде и переделать на джанго. Ну и база есть уже, чего её трогать-то?
    А так для джанго без разницы sqlite, mysql, oracle или mssql. Естественно есть ограничения по транзакциям и с геоджанго своя специфика.
  • AlexB

    Сообщения: 4290 Репутация: N Группа: в ухо

    Spritz 25 мая 2012 г. 6:08, спустя 26 минут 55 секунд


    А так для джанго без разницы sqlite, mysql, oracle или mssql.
    Ровно до тех пор, пока ты не напишешь первое extra(select= или rawsql
    А в любом мало-мальски сложном проекте, его напишешь очень быстро …
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 25 мая 2012 г. 6:42, спустя 34 минуты 4 секунды



    А так для джанго без разницы sqlite, mysql, oracle или mssql.
    Ровно до тех пор, пока ты не напишешь первое extra(select= или rawsql
    А в любом мало-мальски сложном проекте, его напишешь очень быстро …


    1. Большинство rawsql, которые я видел, были написаны от не знания некоторых возможностей ORM. Я за последний год один раз писал rawsql, когда понадобился именно UNION и запрос дал dba заказчика. Года три назад, да, много писал, когда не было явных group by, having, агрегаций.
    2. rawsql не имеет никакого отношения к джанго. Если ты берешься писать "сырые" запросы, то очевидно, что разговариваешь ты уже не с джанго, а с базой. И джанго тут помочь ни чем не может, как и любой ORM, но и мешать тебе не будет. И джанго по прежнему всё равно на каком диалекте ты пишешь - sqlite, mysql и т.д.
  • AlexB

    Сообщения: 4290 Репутация: N Группа: в ухо

    Spritz 25 мая 2012 г. 7:13, спустя 31 минуту 3 секунды


    1. Большинство rawsql, которые я видел, были написаны от не знания некоторых возможностей ORM. Я за последний год один раз писал rawsql, когда понадобился именно UNION и запрос дал dba заказчика. Года три назад, да, много писал, когда не было явных group by, having, агрегаций.
    GROUP_CONCAT (array_agg) самый типичный пример. ИМХО, практически всегда нужен. Про хранимые процедуры я даже не говорю. Многие их просто не используют, а ведь в них вся мощь БД и лаконичность кода скрипта. )))))


    2. rawsql не имеет никакого отношения к джанго. Если ты берешься писать "сырые" запросы, то очевидно, что разговариваешь ты уже не с джанго, а с базой. И джанго тут помочь ни чем не может, как и любой ORM, но и мешать тебе не будет. И джанго по прежнему всё равно на каком диалекте ты пишешь - sqlite, mysql и т.д.
    Да кто с этим спорит, просто уточнил, чтобы новичок не сделал для себя вывод: "Если я взял джанго за основу, то могу гарантировать переезд любого проекта на любую БД за 5 секунд". ))) Хер там …
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 25 мая 2012 г. 7:28, спустя 15 минут 32 секунды


    GROUP_CONCAT (array_agg) самый типичный пример. ИМХО, практически всегда нужен.


    GROUP_CONCAT чисто mysql`ная приблуда. От того, как её зачастую используют - волосы дыбом. Совершенно спокойно без неё живут на других СУБД. Если уж охота юзать, то вот -http://habrahabr.ru/post/87096/ оформленная в ормный агрегат.


    Про хранимые процедуры я даже не говорю. Многие их просто не используют, а ведь в них вся мощь БД и лаконичность кода скрипта. )))))


    Хранимые процедуры - это зло. А вперемешку с ОРМ - это зло в кубе. Как и любое размазывание логики. Не говоря уже, про низкоуровневость и слабость процедурных языков. Зачем писать на pl/sql, когда тут прямо есть питон?
  • AlexB

    Сообщения: 4290 Репутация: N Группа: в ухо

    Spritz 25 мая 2012 г. 8:27, спустя 58 минут 42 секунды


    GROUP_CONCAT чисто mysql`ная приблуда. От того, как её зачастую используют - волосы дыбом. Совершенно спокойно без неё живут на других СУБД.
    Ничего она не чисто mysql-ая. Просто называется везде по разному, а вещь крайне нужная и позволяющая избежать подзапросов и следовательно снизить нагрузку и упростить код. Аналог есть в любой базе. В постгресе, например - array_agg.


    Если уж охота юзать, то вот -http://habrahabr.ru/post/87096/ оформленная в ормный агрегат.
    Отлично. Проект станет также непереносим на другую базу, как и в случае с raw. О чем и речь.


    Хранимые процедуры - это зло. А вперемешку с ОРМ - это зло в кубе. Как и любое размазывание логики. Не говоря уже, про низкоуровневость и слабость процедурных языков. Зачем писать на pl/sql, когда тут прямо есть питон?
    Холивар. Лень спорить. Зло, так зло. Разработчики БД - идиоты, понапридумывали всякой ненужной хуйни. ))))
  • adw0rd

    Сообщения: 22905 Репутация: N Группа: в ухо

    Spritz 25 мая 2012 г. 8:39, спустя 12 минут 25 секунд

    А так для джанго без разницы sqlite, mysql, oracle или mssql

    +pgsql
    Спустя 262 сек.
    Холивар. Лень спорить. Зло, так зло. Разработчики БД - идиоты, понапридумывали всякой ненужной хуйни. ))))

    нет, просто оно уже устарело, и живет по принципу "кому надо будут пользоваться"
    а размазывать логику действительно зло, лучше сразу определеиться либо в БД её поддерживать, либо в коде проекта, но в любом случае всегда есть исключение, если проекту выгоднее иметь пару процедур, то почему нет, главное чтобы в хаос не превращалось и новые члены команды сразу понимали что к чему
    adw/0

Пожалуйста, авторизуйтесь, чтобы написать комментарий!