Sammy95

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

Рекомендуемые сообщения

Sammy95    67

Обнаружил странный кусок кода в файле 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    0

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Fix305    164

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Fix305    164

JavaScript

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Fix305    164

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
afwollis    1 097

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
afwollis    1 097

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
mica    0

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
afwollis    1 097

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

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

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

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

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

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

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

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

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

= = =

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Sammy95    67

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

...

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
UncleAndy    16

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти


  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу