Имя таблицы с магазинами

[discoveri]

Хочу сделать небольшой модуль для магазина, работающий вне контента сайта. Для модуля требуется определить идентификатор магазина. Не могу найти таблицу, в которой хранятся записи о магазинах. У меня не мультимагазин на разных поддоменах, так что, в итоге, идентификатор 0, но на случай расширения магазина, чтоб потом не переделывать, хочется знать, в какой таблице хранится перечень магазинов, чтобы иметь возможность определить идентификатор магазина.

Читал, что идентификатор можно определить таким кодом:

$this->config->get('config_store_id');

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

 

Помогите, плиз, разобраться.

[fanatic]

3 часа назад, discoveri сказал:

в какой таблице хранится перечень магазинов,

oc_store

префикс oc у вас может быть другой

[discoveri]

Спасибо. У меня эта таблица пустая, видимо из-за того, что магазин только 1. Поэтому я там ничего и не нашел. Но теперь буду знать: если что, смотреть туда.

[Yesvik]

В эту таблицу добавляются второй и последующие магазины.

[discoveri]

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

.

[AlexDW]

смотрите как формируется массив данных о магазинах $data['stores'] в admin\controller\setting\store.php

[discoveri]

А кто-то подскажет, что за таблицы category_path и category_to_layout? И вообще, где-то есть описание таблиц?

[chukcha]

43 минуты назад, discoveri сказал:

А кто-то подскажет, что за таблицы category_path и category_to_layout? И вообще, где-то есть описание таблиц?

С какой целью спрашиваете?

[discoveri]

Понять, нужно ли там что-то корректировать скриптом, который делаю. Скрипт вносит изменения в категории. Нужно ли затрагивать category_path и category_to_layout - вот в чем вопрос. Но объяснять назначение скрипта долго. Проще узнать, что за таблицы такие...

[chukcha]

6 минут назад, discoveri сказал:

нужно ли там что-то корректировать скриптом,

Все зависит от того что вы делаете

 category_path  как таковое нигде во фронте не используется, только в даминке - строит дерево категорий

Если вы меняете принадлежность кактегорий или добавляете, т о дерево нужно каждый раз перестраивать

category_to_layout  Если уж вы влезли в опенкрат, то попробуйте сами понять зачем эта эта таблица

[discoveri]

Мне кажется, дерево категорий должно строиться по oc_ca tegory. Для этого там есть поле parent_id

[chukcha]

11 минут назад, discoveri сказал:

Мне кажется, дерево категорий должно строиться по oc_ca tegory. Для этого там есть поле parent_id

так и есть, но для быстрого дерева используется именно эта таблица

Тут даже не сколько дерево, а его ветка от кончика до столба

 

SELECT GROUP_CONCAT(c1.category_id ORDER BY level SEPARATOR '_') path
		FROM oc_category_path cp
		LEFT JOIN oc_category c1 ON (cp.path_id = c1.category_id)
		WHERE cp.category_id = :category_id 
		GROUP BY cp.category_id;

 

[discoveri]

Непонятно, почему это не берется из таблицы oc_category, но, ладно, по ходу пьесы разберусь. Спасибо за пояснение использования.

[chukcha]

10 минут назад, discoveri сказал:

Непонятно, почему это не берется из таблицы oc_category,

потому что  ветка строится рекурсивными запросами, вы знаете простую рекурсию в mySQL

Данный запрос избавляет от рекрусии

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

Вложенность чисто порядковая - т.е. уровень 1, уровень 2, уровень 3
А вот о более глубоких уровнях - полное молчание.. т.е. это становиться ресурсоемким



 

[discoveri]

В 28.10.2019 в 17:05, chukcha сказал:

SELECT GROUP_CONCAT(c1.category_id ORDER BY level SEPARATOR '_') path FROM oc_category_path cp LEFT JOIN oc_category c1 ON (cp.path_id = c1.category_id) WHERE cp.category_id = :category_id GROUP BY cp.category_id;

Это интересное решение, хотя я предпочел бы обходиться без лишней таблицы и высчитывать ветки в реальном времени, так как думаю, чем меньше информации дублируется в базе, тем лучше. Но тут каждый делает по своему вкусу. Да и GROUP_CONCAT там вряд ли нужен.

SELECT c1.category_id
FROM oc_category_path cp
LEFT JOIN oc_category c1 ON (cp.path_id = c1.category_id)
WHERE cp.category_id = :category_id
ORDER BY level 

Дает тот же результат, только не объединенный в строку. Соответственно, потом не нужно её делить. Сразу можно делать обход по результатам выборки...

Хотя... Может где-то и удобней получить строкой...

Змінено 29 жовтня 2019 користувачем discoveri

[discoveri]

Кстати... В oc_category  есть поле "top". Насколько я понял, просто глядя в базу, не анализируя код OpenCart в этом направлении, единица в поле указывает истинность значения и определяет, что категория находится на верхнем уровне. Поскольку тип поля tinyint(1), то, даже не внося изменения в базу, можно задавать там 10 уровней (от 0 до 9). Можно подправить скрипты, чтоб топ был нулевым, а можно начинать счет от единицы, думаю, 9 уровней достаточно для любого магазина. И отмечать уровень вложенности в этом поле, избавившись от лишней таблицы.

Но это так - в порядке теоретических рассуждений. На самом-то деле я бы и таблицу oc_category_path убрал и поле top, сделав расчеты деревьев в реальном времени.

Змінено 29 жовтня 2019 користувачем discoveri