"PHP" / Говнокод #13081 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
if (!$left || !$right) return true;
        $sql = "DELETE FROM {$this->_tableName} WHERE `user_id`=$user_id";
        $this->_db->exec($sql);

        if (!$this->_isTriggers) {
            if (($right - $left) == 1) {
                $sql = "UPDATE {$this->_tableName} SET `left`=IF(`left` >= $left,`left`-2,`left`),`right`=`right`-2 WHERE `right` >= $left";
            } else {
                $sql = "UPDATE {$this->_tableName} SET 
                `left`=IF(`left` BETWEEN $left AND $right,`left`-1,`left`),
                `right`=IF(`right` BETWEEN $left AND $right,`right`-1,`right`),
                `level`=IF(`left` BETWEEN $left AND $right,`level`-1,`level`),
                `left`=IF(`left`>$right,`left`-2,`left`),
                `right`=IF(`right`>$right,`right`-2,`right`)
		WHERE `right` > $left
                ";
            }
            $this->_db->exec($sql);

Только ручной сбор запроса. Zend Db

Запостил: coderxlsn coderxlsn, (Updated )

Комментарии (21) RSS

  • Да бог сним с ручным сбором что за колдунство if (!$left || !$right) return true;
    или if (!$this->_isTriggers)

    Сss в sql ?
    Ответить
    • > if (!$this->_isTriggers)
      Рискну предположить, что так проверяется поддержка триггеров в текущей СУБД. И если это мистер мускуль ниже 5.0.2 триггеров нет - хуячим руками.

      А колдунство с left и right это, с вероятностью 146%, удаление ноды из дерева, представленного в виде nested set'а.
      Ответить
  • Ээх... а еще пост дедушки Борманда подсветили зеленым http://govnokod.ru/13072#comment178864... На полном серьезе же писал...

    Dates ... TEST SKIPPED
    Manual query building ... OK
    MySQL only ... OK
    Non-atomic logic without transactions ... OK
    Scan result: genuine PHP style detected.
    Ответить
    • > MySQL only
      Ну оно какбэ обычно на то и расчёт. Других баз почти не существует, да и не нужны они.
      Я вот теперь серьёзно думаю переводить проекты на постгрес, а поддержку mysql сделать deprecated.
      Ответить
      • > Я вот теперь серьёзно думаю переводить проекты на постгрес, а поддержку mysql сделать deprecated
        Луч света в тёмном царстве...
        Ответить
          • В том, что он ближе к стандарту и другим субд. Ну и выебонов, включенных по дефолту типа || как логическое или, волоса тых полей или рандомного выбора в групбай я в нем не встречал.

            После общения с постгресом с мускулом возиться влом, хотя к сожалению недавно пришлось (см. Кабинку).
            Ответить
          • С ним-то можно жить, но бывают очень неприятные рандомные глюки. Самое неприятное из запомнившегося, это когда INT NULL + FOREIGN KEY поле меняли на NOT NULL... На проде таки нашлись строчки, для которых предшествующий UPDATE не нашёл айдишник и они остались NULL... Эта "№;%:? даже не ругнулась, молча влепила туда нолики несмотря на ключ... Только узнали мы это через 2 дня, отлавливая "да ну быть того не может, ключ не дал бы" по жалобе клиента. Это совпало ещё с попавшим в больницу админом и запоротыми бекапами, 🙁 знатный получился факап данных...
            Ответить
            • Омг. В поле с FK лежали нолики вместо NULL'ов и правильных значений?
              Ответить
              • Ну да, ALTER TABLE some_tbl MODIFY fk_col INT NOT NULL влепил молча нолики вместо имевшихся NULL-ов... Потом так и не воспроизвели в точности как было - ворнинги таки выдаёт. Но нолики так же ставит. 🙂
                "На мускуль надейся, а код проверяй."

                ...А вот если ключ на время убрать, а после изменения на NOT NULL заново создать - тогда не пускает, ругается.
                Ответить
          • У mysql'я, емнип, один плюс - есть аналог merge из нормальных баз. Там он называется, кажется, insert or update. Необходимость его чаще всего иллюзорная, но пару раз спасало день.
            Ответить
            • У MySQL есть REPLACE и есть INSERT ... ON DUPLICATE KEY UPDATE. Оба не соответствуют MERGE из SQL:2003.
              Ответить
                • Я даже не знаю, как их сравнивать. У них разная семантика. Мускуловские REPLACE и INSERT ODKU предназначены для вставки небольшого количества строк. Выбор между вставкой и заменой по простому условию: отсутствие или наличие в базе строки по заданному ключу. ODKU — это сленговое сокращение, чтобы не писать много.

                  У стандартного MERGE страшноватый синтаксис: он требует наличия таблицы (пусть и временной), из которой копировать, и допускает более сложное условие для выбора между вставкой и заменой. Вроде и более гибко, но будет страшно выглядеть, если нам всего лишь нужно вставить одну строку констант.

                  Кстати, у MySQL есть ещё одна нестандартная вещь: движок под названием MERGE, чтобы совсем нескучно было. CREATE TABLE ... ENGINE=MERGE UNION=(таблица1, таблица2) мержит две таблицы типа MyISAM.
                  Ответить
                  • > CREATE TABLE ... ENGINE=MERGE UNION=(таблица1, таблица2) мержит две таблицы типа MyISAM
                    Это эффективней, нежели view на union'е?
                    Ответить

Добавить комментарий

Помни, guest, за тобой могут следить!

    А не использовать ли нам bbcode?


    8