Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Sign Up

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


Recommended Posts

Обнаружил странный кусок кода в файле 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...
Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

JavaScript

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

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

Link to post
Share on other sites

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

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

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

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

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

Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

= = =

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

Link to post
Share on other sites

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

...

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

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

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

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

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

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

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

  • +1 1
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.