Вопросы по коду движка магазина

[Sammy95]

Обнаружил странный кусок кода в файле admin/model/setting/setting.php:

public function editSetting($group, $data) { 
        $this->db->query("DELETE FROM " . DB_PREFIX . "setting WHERE `group` = '" . $this->db->escape($group) . "'"); 
         
        foreach ($data as $key => $value) { 
            $this->db->query("INSERT INTO " . DB_PREFIX . "setting SET `group` = '" . $this->db->escape($group) . "', `key` = '" . $this->db->escape($key) . "', `value` = '" . $this->db->escape($value) . "'");
        } 
    }

Вопрос: а нафига сначала всё удалять, а затем снова добавлять, если надо всего-лишь внести изменения? Ведь однажды так можно и нарваться на предел значений поля с Auto Increment...

[mezzy]

Так меньше нагрузка на БД и на сервер. Ведь некоторые настройки могли быть выключены/сброшены

[Sammy95]

Судя по коду, выключенные/сброшенные настройки там просто меняют своё значение в поле `value`.

И я всегда считал, что UPDATE обходится дешевле, чем DELETE с последующим INSERT. Но даже если это и не так, то в любом случае это просто смешная нагрузка применительно к изменениям настроек. А вот исчерпание значений Auto Increment выглядит более серьёзным злом. Да и вообще, при таком подходе, какой тогда смысл в поле с Auto Increment? - по нему же всё-равно нельзя ничего найти.

[Fix305]

если есть какие то данные, которые добавляются через JS, редактируется и там же удаляются, то получается такой массивчек где не понятно какую запись надо сделать INSERT, какую UPDATE, а какую то вообще DELETE, а данная конструкция удаляет все и добавляет все что осталось в форме.

исчерпание значений auto increment что то невероятное, такое на моей памяти было только 1 раз (не спорю что где то было еще) в twitter'e и им пришлось изменить разрядность поля =)

[Sammy95]

Можно сделать SELECT и затем сравнить массивы... Но в целом понятно, значит разработчики пошли по пути наиболее простой реализации. Хотя подход какой-то странный, ИМХО.

А что это за JS такой? Через него можно добавить свои параметры?

[Fix305]

JavaScript

[Sammy95]

Fix305: я понял, что речь про яваскрипт :) Имелось ввиду - где в опенкарте можно посмотреть примеры подобного добавления/редактирования/удаления данных? Или это всё было лишь гипотетическим предположением?

[Fix305]

насчет именно setting в стандартной комплектации сразу так вспомнить не могу, я, например, делал модуль скидок там как раз использовал эту фишку, ну а если не setting то ярким примером могут послужить вкладки "Атрибуты", "скидки, "специальное", "изображения" в редактировании товара

[Sammy95]

Понятно, выходит, что это стандартный способ для движка опенкарта по внесению изменений в базу. А что будет, если между DELETE и INSERT на сайт зайдёт клиент? - он получит страницу со сброшенными настройками или этот момент как-то обходится?

[afwollis]

А что будет, если между DELETE и INSERT на сайт зайдёт клиент?

у вас сайт грузится быстрее, чем отрабатывает конструкция "delete, insert" ? O_O

можно мне узнать секрет такой "ракетизации" ?

[Sammy95]

afwollis: а при чём тут скорость загрузки? MySQL в общем случае выполняет запросы в порядке поступления, и верятность выполнения нежелательного SELECT после DELETE, но до всех нужных INSERT - зависит только от случая и посещаемости ресурса.

Или тут у всех апач работает одним бестредовым процессом?

[afwollis]

что-то я о последовательности выполнения запросов совсем забыл.

никакой специальной защиты от проблем такого плана в движке нет.

хотя, наличие кэша можно считать "заплаткой" в некотором смысле.

[mica]

ребята. зачем ломать копья? :) таблицы 1.4.9.3(к примеру) созданы на myisam. там в принципе не может быть коммитов и роллбэков, а сразу автокоммит. ну ,а что лучше - myisam либо innodb(опять же к примеру), имхо не в этом форуме.

[Sammy95]

mica: движок для таблиц здесь не при чём, просто на первый взгляд БД и работа с ней спроектированы не самым лучшим образом. И тормоза, возникающие при большом кол-ве категорий, указывают именно на это.

afwollis: Спасибо за ответы. Осталась ещё парочка вопросов:

Если в админке изменить пункт "Единица веса" в Система->Локализация->Единицы веса, который установлен "По умолчанию" (например "kg" заменить на "кг."), то установка "По умолчанию" слетает и в корзине показываются только цифры (без идентификатора единиц веса) до тех пор, пока в Система->Настройки снова не выставить нужные единицы веса. Я выяснил, что в таблице setting это значение хранится в виде текста (строка `group`="config", `key`="config_weight_class", `value`="kg").

Вопрос 1: если хранить там не текст, а ID этой величины (таблица weight_class_description, колонка `weight_class_id`) - может ли это поломать совместимость с какими-то сторонними модулями опенкарта?

Вопрос 2: что в подобных случаях делают разработчики ocStore - забивают на баг ради совместимости или как-то решают вопрос?

[afwollis]

Насчет тормозов:

1. При большом количестве категорий:

Первый раз будет долго формироваться страница: перелопатить множество категорий для вывода в поиске в шапке магазина (как у некоторых тут было - тысячи :) ) дело не легкое.

Но потом это дело будет браться из кэша.

2. Дело в том, что авторы движка пошли по пути наименьшего сопротивления.

Практически в каждом запросе в БД они выбирают МАКСИМУМ полей (как говорится - "чтоб было").

С одной стороны это облегчает задачу вывода доп.информации на той или иной странице - данные уже есть в контроллере, надо просто передать их в шаблон.

С другой стороны - это лишняя нагрузка.

Так что любому конкретному проекту можно "добавить газку", оптимизировав все запросы.

= = =

Ответ 1: а зачем? пусть все так и остается. Просто надо добавить обработку этого значения и подставлять "kg", "кг", "фунты", "мб", "чо-угодно" из языковых файлов.

[Sammy95]

Первый раз будет долго формироваться страница:

...

Но потом это дело будет браться из кэша.

Насколько я понял из формулировки вопроса и вашего ответа на него - кэш не особо помогает.

2. Дело в том, что авторы движка пошли по пути наименьшего сопротивления.

Это я и имел ввиду, когда говорил что работа с БД сделана не самым лучшим образом.

Ответ 1: а зачем? пусть все так и остается. Просто надо добавить обработку этого значения и подставлять "kg", "кг", "фунты", "мб", "чо-угодно" из языковых файлов.

Изначально движок сделан так, что значение берётся из базы. А я подхожу (пытаюсь подходить) к проблемам с позиции "исправь один раз как положено и отправь решение в апстрим". Мне этот путь кажется более выгодным, чем исправление одного и того же каждый раз при обновлениях движка. Вот поэтому я и задал эти два вопроса.

[UncleAndy]

Возможно работу с БД получится поправить. В контексте написания драйвера для Posgresql автор OpenCart вроде-бы согласился поправить синтаксис SQL запросов на более стандартный. Может быть получится его убедить на использование update/insert в этом случае.