Перейти к содержанию

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

Я опять тут за помощью.

Насколько я знаю у opencart pro есть кэширование запросов в базу.

Похоже я напоролся с этим кэшированием на геморрой.

У меня то читаются и пишутся поля в базу, то перестают это делать, непонятно почему.

$calcjson=json_encode($data['calcparams']);
$this->db->query("UPDATE " . DB_PREFIX . "product SET calculator='" . $this->db->escape($data['selected-calculator']) . "' WHERE product_id = '" . (int)$product_id . "'");// это поле пишется и читается номрально
$this->db->query("UPDATE " . DB_PREFIX . "product SET parametres='" . $this->db->escape($calcjson) . " WHERE product_id = '" . (int)$product_id . "'");// это поле сейчас не пишется и не читается, вчера и сегодня утром читалось без проблем

Кто-нибудь сталкивался с такой проблемой?

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


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

Потеряли один символ

$this->db->query("UPDATE " . DB_PREFIX . "product SET parametres='" . $this->db->escape($calcjson) . "' WHERE product_id = '" . (int)$product_id . "'");

 

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


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

Да нет, это я правил строку, и пропустил кавычку, думал кодировка в json барахлит, и тупо в запросе пробовал так:

$this->db->query("UPDATE " . DB_PREFIX . "product SET parametres='ggggggg' WHERE product_id = '" . (int)$product_id . "'");

Один пень не пишет. Я в отчаянии. что делать - не знаю.

Кроме этого даже чтение из базы по нулям из этого поля как будто его нет, а он ЕСТЬ.

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


Ссылка на сообщение
Поделиться на другие сайты
17 минут назад, amfsota сказал:

Один пень не пишет. Я в отчаянии. что делать - не знаю.

Обновляются поля из фронта ?
Если включен Turbo - то понятное дело обновляться они не будут, так как код их выполняться не будет

Отключать Turbo

 

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


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

Похоже мы с Вами в другом форуме общаемся))

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


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

Это точно что в другом, но не форуме, а формате

 

Есть кеш?

   НЕТ

      код контроллера

      update

     готовим кеш

      отдать кеш

  Да

  отдать кеш

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


Ссылка на сообщение
Поделиться на другие сайты
21 минуту назад, amfsota сказал:

Похоже мы с Вами в другом форуме общаемся))

У вас сборка opencart.pro стоит ?

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


Ссылка на сообщение
Поделиться на другие сайты
11 минут назад, chukcha сказал:

Это точно что в другом, но не форуме, а формате

 

  Да

  отдать кеш

При полностраничном кешировании кешировщиком код контроллеров фронта исполняться не будет
Соответственно не будет исполняться и код ТС (если он во фронте)
Надо кешер умеющий по контроллерно кешировать ;)
Или выключать полностраничный кешировщик

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


Ссылка на сообщение
Поделиться на другие сайты
32 минуты назад, markimax сказал:

У вас сборка opencart.pro стоит ?

Да Pro Версия 2.1.0.1.10

кеш менеджер включен

в процессе тестов постоянно обновлял и системный кеш и картинки - без толку.

Сейчас все запросы работают и из админки и из каталога.

А когда глюки начинаются, только phpmyadmin может вносить изменения в базу.

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


Ссылка на сообщение
Поделиться на другие сайты
47 минут назад, chukcha сказал:

Это точно что в другом, но не форуме, а формате

 

Есть кеш?

   НЕТ

      код контроллера

      update

     готовим кеш

      отдать кеш

  Да

  отдать кеш

Это каждый запрос к базе так обслуживать?

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


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

Это так работает полностраничное кеширование, о чем вам и говорил markimax

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


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, chukcha сказал:

Это точно что в другом, но не форуме, а формате

 

Есть кеш?

   НЕТ

      код контроллера

      update

     готовим кеш

      отдать кеш

  Да

  отдать кеш

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

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


Ссылка на сообщение
Поделиться на другие сайты
4 минуты назад, EVMedvedev сказал:

Формулировка некорректна,

Поясните некорректность полностраничного кеша?

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


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, EVMedvedev сказал:

если речь идет о кэшировании запросов к базе данных.

именно к базе

со страницами всё в порядке

проблема с запросами, то работают, то - нет

причём выборочно, одни поля пишет и читает, другие - нет

Изменено пользователем amfsota

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


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, chukcha сказал:

Поясните некорректность полностраничного кеша?

Вместо кода контроллера нужен код модели, то есть то место, где формируется запрос к базе данных. Ключом данных в кэше является хэш SQL-запроса. Полностраничный кэш - это когда в кэше хранится весь HTML-код страницы. Тогда соответственно перехват страницы нужно делать на уровне роутинга. Например в Action, но получается опять же не в контроллере.

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


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

Покажите некорректность

 

на каком этапе проверяется наличие кеша?

4 минуты назад, EVMedvedev сказал:

Вместо кода контроллера нужен код модели

 

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


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, amfsota сказал:

именно к базе

со страницами всё в порядке

проблема с запросами, то работают, то - нет

причём выборочно, одни поля пишет и читает, другие - нет

Если поля выборочно пишутся или теряются, то соответственно либо проблемы сериализации и десериализации (данные из БД нужно преобразовывать в строку для записи в кэш и обратно в массив) либо потери данных в самом кэше.

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


Ссылка на сообщение
Поделиться на другие сайты
12 часов назад, chukcha сказал:

Покажите некорректность

 

на каком этапе проверяется наличие кеша?

 

Так написано же. Для полностраничного кэширования в Action (если точнее, то в Action::execute), чтобы даже URL не разбирать, если для него есть кэш. Для модели - в момент после сбора полного SQL-запроса и перед его исполнением. В первом случае делаем ключ для кэша из урла, во втором - из SQL-запроса. Обычная практика во всех движках.

Кстати отсутствие в Opencart ORM движка для работы с базой данных, как например в Symfony, осложняет кэширование данных. В Symfony, а значит на всех системах на его основе, кэширование данных встроено в Doctrine централизовано.

Изменено пользователем EVMedvedev

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


Ссылка на сообщение
Поделиться на другие сайты
16 часов назад, amfsota сказал:

Да нет, это я правил строку, и пропустил кавычку, думал кодировка в json барахлит, и тупо в запросе пробовал так:


$this->db->query("UPDATE " . DB_PREFIX . "product SET parametres='ggggggg' WHERE product_id = '" . (int)$product_id . "'");

Один пень не пишет. Я в отчаянии. что делать - не знаю.

Кроме этого даже чтение из базы по нулям из этого поля как будто его нет, а он ЕСТЬ.

А вы уверены, что product_id у вас приходит нормальный ?

сделайте после этой конструкции $this->log->write("update .... ) и посмотрите что у вас пишет на самом деле.
Я подозреваю проблема в том, что вы просто кривой айдишник передаете и он или нулевой или его нету.

А про кеширование запросов в базу - чушь!

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


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, EVMedvedev сказал:

Так написано же. Для полностраничного кэширования в Action (если точнее, то в Action::execute), чтобы даже URL не разбирать, если для него есть кэш. Для модели - в момент после сбора полного SQL-запроса и перед его исполнением. В первом случае делаем ключ для кэша из урла, во втором - из SQL-запроса. Обычная практика во всех движках.

Кстати отсутствие в Opencart ORM движка для работы с базой данных, как например в Symfony, осложняет кэширование данных. В Symfony, а значит на всех системах на его основе, кэширование данных встроено в Doctrine централизовано.

Обшибся, каюсь. Не Action::execute, а скорее Front::dispatch. В других движках алгоритмы другие. Сначала работает routing, то есть разбор урлов, а уже потом запускается контроллер. Там уже поздно кэшировать.

В этом смысле вы видимо имели ввиду "контроллер" это переменная $controller в index.php в которой и сидит объект класса Front. Тогда все верно.

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


Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, snastik сказал:

А вы уверены, что product_id у вас приходит нормальный ?

сделайте после этой конструкции $this->log->write("update .... ) и посмотрите что у вас пишет на самом деле.
Я подозреваю проблема в том, что вы просто кривой айдишник передаете и он или нулевой или его нету.

А про кеширование запросов в базу - чушь!

Так вот и я думаю, что чушь.

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

Первый запрос пишет в базу данные, второй-нет, как будто стоит запрет на запись или чтение из поля 'parametres'.

Может ли mysql ограничивать доступ к определённым полям таблицы?

Наверное версию с кешированием запросов от Opencart надо отбросить...

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


Ссылка на сообщение
Поделиться на другие сайты
26 минут назад, amfsota сказал:

Так вот и я думаю, что чушь.

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

Первый запрос пишет в базу данные, второй-нет, как будто стоит запрет на запись или чтение из поля 'parametres'.

Может ли mysql ограничивать доступ к определённым полям таблицы?

Наверное версию с кешированием запросов от Opencart надо отбросить...

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

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


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

Спасибо, если база не ограничивает доступ значит что-то не так в коде.

Буду копать.

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


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

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

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

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

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

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

Войти

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

Войти

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

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

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.