Вопросы специалистов

Документация для специалистов

Tips & tricks

xPDO: все поля присоединённых таблиц типизирует как строковые

Джоины подзапросов средствами xPDO

Удаление записей сразу из нескольких таблиц средствами xPDO

Заставить — никак. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы (на самом деле может, но, думаю, не будет этого делать, слишком много тонкостей и вариантов здесь). А вот сформировать правильный запрос можно.
 

$query->innerJoin('modTemplateVarTemplate', 'TVValues', "TVValues.contentid = modResource.id AND TVValues.tmplvarid = 8");

Если уж очень хочется именно в where засунуть условие, то так:
 

$query->where(array('TVValues.tmplvarid = 8'));

P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate.

Заставить — никак. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы (на самом деле может, но, думаю, не будет этого делать, слишком много тонкостей и вариантов здесь). А вот сформировать правильный запрос можно. $query->innerJoin('modTemplateVarTemplate', 'TVValues', "TVValues.contentid = modResource.id AND TVValues.tmplvarid = 8"); Если уж очень хочется именно в where засунуть условие, то так: $query->where(array('TVValues.tmplvarid = 8')); P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate.

Заставить — никак. Он не может знать является ли у

P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate. 

Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы

Так ведь в методе innerJoin первым параметром передаётся имя xPDO-объекта, вторым псевдоним, третьим — условие с использованием этого псевдонима. Если название таблицы в составе условия совпадает с псевдонимом, указанным вторым параметром, то однозначно это псевдоним xPDO-объекта, указанного первым параметром. Иначе быть не может, поскольку в выборке не могут участвовать 2 таблицы с одинаковыми псевдонимами.
 

Т.е. алгоритм проверки должен быть таким:
 1) если имя таблицы в условии совпадает с псевдонимом присоединяемой таблицы => это и есть присоединяемая таблица => типизируем как положено
 2) если имя таблицы в условии не совпадает с псевдонимом присоединяемой таблицы => парсим поле как строковое (т.к. ситуация неопределённая)
 И xPDO этой элементарной проверки почему-то не выполняет…
 

А вот сформировать правильный запрос можно.

Я просто пример привёл такой со стандартной таблицей. В этом примере — да, логически правильнее внести фильтрацию по TV в ON. Но во многих других случаях (в т.ч. и с участием собственных таблиц) дополнительные условия должны содержаться в WHERE. Особенно, если запрос большой и частично он строится в одних методах, частично — в других.
 

В любом случае, проблема имеет место, не зависимо от того, где присутствует условие — в WHERE или в ON.


P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate. Да, верно. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы Так ведь в методе innerJoin первым параметром передаётся имя xPDO-объекта, вторым псевдоним, третьим — условие с использованием этого псевдонима. Если название таблицы в составе условия совпадает с псевдонимом, указанным вторым параметром, то однозначно это псевдоним xPDO-объекта, указанного первым параметром. Иначе быть не может, поскольку в выборке не могут участвовать 2 таблицы с одинаковыми псевдонимами. Т.е. алгоритм проверки должен быть таким:
 1) если имя таблицы в условии совпадает с псевдонимом присоединяемой таблицы => это и есть присоединяемая таблица => типизируем как положено
 2) если имя таблицы в условии не совпадает с псевдонимом присоединяемой таблицы => парсим поле как строковое (т.к. ситуация неопределённая)
 И xPDO этой элементарной проверки почему-то не выполняет… А вот сформировать правильный запрос можно. Я просто пример привёл такой со стандартной таблицей. В этом примере — да, логически правильнее внести фильтрацию по TV в ON. Но во многих других случаях (в т.ч. и с участием собственных таблиц) дополнительные условия должны содержаться в WHERE. Особенно, если запрос большой и частично он строится в одних методах, частично — в других. В любом случае, проблема имеет место, не зависимо от того, где присутствует условие — в WHERE или в ON.

P.S. И вероятно предполагалось modTemplateVarResou

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня…
 

Всё-таки отказ от автоматической xPDO-типизации в условиях — не совсем хороший вариант. Хотя бы, те же самые операторы IN. Напрашивается такое решение: обёртка для join'ов, в которых:
 а) вручную читаем мета-данные
 б) определяем тип
 в) корректируем тип поля в объекте xPDOQuery (query['joins'][...])
 

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам…

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня… Всё-таки отказ от автоматической xPDO-типизации в условиях — не совсем хороший вариант. Хотя бы, те же самые операторы IN. Напрашивается такое решение: обёртка для join'ов, в которых:
 а) вручную читаем мета-данные
 б) определяем тип
 в) корректируем тип поля в объекте xPDOQuery (query['joins'][...]) Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам…

Вообще, у меня в коде много десятков подобных запр

Если уж очень хочется именно в where засунуть условие, то так:
 $query->where(array('TVValues.tmplvarid = 8'));

И xPDO этой элементарной проверки почему-то не выполняет…

Отправляйте свой PR в xPDO, не вопрос.

Если уж очень хочется именно в where засунуть условие, то так:
 $query->where(array('TVValues.tmplvarid = 8')); И xPDO этой элементарной проверки почему-то не выполняет… Отправляйте свой PR в xPDO, не вопрос.

Если уж очень хочется именно в where засунуть усло

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня…

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Хотите более полный контроль над типами? — юзайте CAST, CONVERT и т.п.

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня… У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Хотите более полный контроль над типами? — юзайте CAST, CONVERT и т.п.

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам… 

Не вижу смысла. Не помогу с этим.

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам… Не вижу смысла. Не помогу с этим.

Здорово поможете, если навскидку состряпаете эту о

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка.

Именно. Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу)

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Именно. Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу)

У вас где-то запрос не так выполняется (имеется вв

Тьфу, что-то не то пишу. Должно нормально работать сравнение. Проверю ещё раз…

Тьфу, что-то не то пишу. Должно нормально работать

Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу) 

Да, вы явно не то пишете. Все будет ОК работать. Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'.

Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу) Да, вы явно не то пишете. Все будет ОК работать. Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'.

Сравнение числового поля со строковой константой в

Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'. 

И в условиях сравнения тоже.

Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'. И в условиях сравнения тоже.

Это в сортировках может получиться, что '87' будет

Больше/меньше — да, но равно/не равно — нет.

Всё равно некошерно. Ладно, с TV понятно — если там сравнение на неравенство используется, нужно непосредственно прописывать условие в виде SQL. Но когда то же самое приходится делать с собственными типизированными таблицами — это уже извращение.

Всё равно некошерно. Ладно, с TV понятно — если та

Еще раз — шлите пуллреквесты, улучшайте работу MODX-а. Я вот шлю. На сегодня более 10% всех активных PR в MODX — мои. И вы можете приложить усилия, чтобы MODX стал лучше.

Еще раз — шлите пуллреквесты, улучшайте работу MOD

На английском не очень получается. Впрочем, писал уже:
 github.com/modxcms/revolution/issues/12307
 ноль внимания…
 

Хотя в версии 2.3.3 они там логику чуть изменили (так, что в описанных в этой теме условиях ошибки больше не вылезали), но «корячность» этой логики сохранилась (а может, я её не понимаю). Так или иначе в 2.3.3 эти 2 ошибки по-прежнему иногда вылезают, но гораздо реже и при других условиях (при каких — неизвестно).
 

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее.

На английском не очень получается. Впрочем, писал уже:
 github.com/modxcms/revolution/issues/12307
 ноль внимания… Хотя в версии 2.3.3 они там логику чуть изменили (так, что в описанных в этой теме условиях ошибки больше не вылезали), но «корячность» этой логики сохранилась (а может, я её не понимаю). Так или иначе в 2.3.3 эти 2 ошибки по-прежнему иногда вылезают, но гораздо реже и при других условиях (при каких — неизвестно). Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее.

На английском не очень получается. Впрочем, писал 

Issue — это только пожелания, обсуждения. Отправить готовый код — более предметно.

Issue — это только пожелания, обсуждения. Отправит

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее. 

Нет. С разбегу не получится. Не 5 минут…
 

Логика должна быть такой. Перед выполнением метода prepare() запускается наша супер-функция (или метод), которая в объекте xPDOQuery делает следующее:
 1) проходит по всем JOIN-таблицам и в их condition'ах корректирует ['condition']['bind']['type'], если он не соответствует модели таблицы
 2) нестроковые условия по TV полям преобразовывает в их SQL-аналоги с использованием CAST'ов в зависимости от типа TV, задаваемого в modx_site_tmplvars
 3) то же самое — для полей, участвующих в ORDER BY и HAVING
 

Тогда работа с xPDO станет сказкой…
 А пока не горит. Нестроковые сравнения (< > <= >=) и сортировки по TV-полям и JOIN-полям оформляем в виде SQL с CAST'ами, всё остальное — оставляем как есть.

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее. Нет. С разбегу не получится. Не 5 минут… Логика должна быть такой. Перед выполнением метода prepare() запускается наша супер-функция (или метод), которая в объекте xPDOQuery делает следующее:
 1) проходит по всем JOIN-таблицам и в их condition'ах корректирует ['condition']['bind']['type'], если он не соответствует модели таблицы
 2) нестроковые условия по TV полям преобразовывает в их SQL-аналоги с использованием CAST'ов в зависимости от типа TV, задаваемого в modx_site_tmplvars
 3) то же самое — для полей, участвующих в ORDER BY и HAVING Тогда работа с xPDO станет сказкой…
 А пока не горит. Нестроковые сравнения (< > <= >=) и сортировки по TV-полям и JOIN-полям оформляем в виде SQL с CAST'ами, всё остальное — оставляем как есть.

Что касается сабжа, то лучше я обёртку напишу. Так

А что с производительностью, ведь подзапросы нагружают базу?
 Может быть я чего-то не понимаю, но почему бы не сделать leftJoin modResource и modUser, или это просто пример не удачный?

А что с производительностью, ведь подзапросы нагру

Пример не неудачный, он просто простой. Вот пример посложнее:

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


$q2 = $this->modx->newQuery($this->classKey);

$offersAlias = "offer";

$q2->setClassAlias($offersAlias);

$q2->select(array(
"property_198",
"GROUP_CONCAT({$offersAlias}.id SEPARATOR '||') as offers_id", 
"GROUP_CONCAT({$offersAlias}.price SEPARATOR '||') as prices", 
"GROUP_CONCAT({$offersAlias}.article SEPARATOR '||') as articles", 
"GROUP_CONCAT({$offersAlias}.packaging SEPARATOR '||') as packages", 
));

$q2->where(array(
"{$offersAlias}.published" => 1,
"{$offersAlias}.deleted" => 0,
"{$offersAlias}.hidemenu" => 0,
"{$offersAlias}.property_198:!=" => "", 
));

$q2->groupby("{$offersAlias}.property_198");

$q2->prepare();

$sql = $q2->toSQL();

$c->query['from']['joins'][] = array(
"type" => "left join",
"table" => "({$sql})",
"alias" => "t1",
"conditions" => array(
new xPDOQueryCondition(array(
"sql" => "{$alias}.property_198 = t1.property_198",
)),
),
);

$c->select(array(
"if(t1.offers_id IS NOT NULL, t1.offers_id, {$alias}.id) as offers_id", 
"if(t1.prices IS NOT NULL, t1.prices, {$alias}.price) as prices", 
"if(t1.articles IS NOT NULL, t1.articles, {$alias}.article) as articles", 
"if(t1.packages IS NOT NULL, t1.packages, {$alias}.packaging) as packages", 
));

SELECT 
if(modResource.remains > 0 , 1, 0) as in_store, 
if(t1.offers_id IS NOT NULL, t1.offers_id, modResource.id) as offers_id, 
if(t1.prices IS NOT NULL, t1.prices, modResource.price) as prices, 
if(t1.articles IS NOT NULL, t1.articles, modResource.article) as articles, 
if(t1.packages IS NOT NULL, t1.packages, modResource.packaging) as packages, 
FROM 
`modx_site_content` AS `modResource` 
left join (
SELECT `property_198`, 
GROUP_CONCAT(offer.id SEPARATOR '||') as offers_id, 
GROUP_CONCAT(offer.price SEPARATOR '||') as prices, 
GROUP_CONCAT(offer.article SEPARATOR '||') as articles,
GROUP_CONCAT(offer.packaging SEPARATOR '||') as packages 
FROM 
`modx_site_content` AS `offer` 
WHERE ( 
`offer`.`published` = 1 
AND `offer`.`deleted` = 0 
AND `offer`.`hidemenu` = 0 
AND `offer`.`property_198` != '' 
) 
GROUP BY offer.property_198 
) `t1` 
ON modResource.property_198 = t1.property_198 
WHERE ( 
(
`modResource`.`deleted` = 0 
AND `modResource`.`hidemenu` = 0 
AND `modResource`.`published` = 1 
) 
AND `modResource`.`template` in (3,21) 
)

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

Пример не неудачный, он просто простой. Вот пример

На счет производительности: не самый шустрый вариант, конечно, но более хитрый вариант без подзапроса с дополнительными условиями вообще мускул ложили. В целом, джоинить такой подзапрос не особо нагруженно, так как там получается связь один-к-одному. Здесь выборка из нескольких килотоваров на холодную 2 секунды занимает. Запросы кешируются, так что в целом сайт будет работать нормально.

На счет производительности: не самый шустрый вариа

delete

InnerJoin

JOIN

LeftJoin

MySQL

mysql delete from two tables

xPDO

xpdoquery

сложные запросы

типы данных

типы полей

# Николай Ланец aka Fi1osof
**Lead Fullstack Developer / Ментор / Евангелист современного JS‑стека**

---

## О себе

Я — не просто Senior Developer с 2007 года. Я — тот, кто строит продукты будущего на базе современных технологий и помогает другим подниматься на новую ступень айти-карьеры. Создатель и идейный вдохновитель freecode.academy — платформы, где обучение перестает быть скучной обязаловкой и становится настоящим технологическим приключением.

---

## Мой стек и философия разработки

Основу моего рабочего арсенала составляют:

- [Javascript](/technologies/ck1faudv928l40a89c4u9zxlm), [TypeScript](/technologies/ckcvwwx010kov08009u7y2rav)
- [React](/technologies/ck1fawbdw28v20a891k4wlh27), [Next.js](/technologies/ckg2jd4ffr9260730aog66dri)
- [Node.js](/technologies/ckt55wm59272831wo9gg9r8ynx), [GraphQL](/technologies/ck1fawhqk28vu0a8995lqvlsj), [Apollo Client](/technologies/ck2zdcg0vpvc10a89xjmhj1e0), [Nexus](/technologies/ckl2pbh0fxew60730ifl3zozp), [Prisma](/technologies/ck2zdbmi7pv8r0a89ntc2r0f1)
- DevOps: [Docker](/technologies/ck2y1x9lho9cy0a8953xzfjr8), [docker-compose](/technologies/ck2y1xqino9g80a89tsftxin2), [Caddy](/technologies/ck2zd8ovqpuyl0a8909748sbu), [Ubuntu](/technologies/cktu8giks3593911vmle30ztqxt)
- UI-инструменты: [Styled-Components](/technologies/ckk8myysio7lw0730csszvrdw), [Material-UI](/technologies/ckljv3jwd7bgf0730huxlko9n), [react-hook-form](/technologies/ckmx8cn9fmwrv073032e67722)
- Всё актуальное для разработки, CI/CD и автоматизации 
- Эксперименты с [WebGL](/technologies/ckan9anntc12f08003saqttrq), [A‑Frame](/technologies/ck2tgoiz8j37y0a89c7gxsrxc), [Three.js](/technologies/ck2tgns1nj32z0a89vmw7xw3f), [Unreal Engine 4](/technologies/ck7puswy6g4yb07004cdp6lbr), [Elixir](/technologies/ckn0olavrnnzi0730xs8rctn8), [C++](/technologies/cknin1y8lu2fr07307mskn2fn)

---

## Разработка и менторство

- Более 15 лет **hands-on** разработки и проджект‑менеджмента
- Главный разработчик и преподаватель платформы [freecode.academy](https://freecode.academy)
- **Ведущий менти-пул на платформе** — лично выращиваю новых звезд отрасли

### Мои менти и их результаты

| Менти (ФИО \| username)                               | Уровень | Рейтинг |
|-------------------------------------------------------|---------|---------|
| [Попов Дмитрий \| linklib](/users/cjoe890c706ji0d962oismzoe)           | 3       | 315     |
| [Сэт \| defk1lla](/users/ckzh1ita312978121imr9hpqfc64)                 | 3       | 670     |
| [Ксения Матвеева \| Ксения Матвеева](/users/ckz4awwlh10627771imr4wvpb7cj) | 2       | 0       |
| [Михаил \| Balamut](/users/cl1npq92z10258261vmbq0w6vfh2)               | 2       | 0       |
| [Ольга Ершова \| angel](/users/cjoe87zhk00250d969arluevk)              | 1       | 0       |
| [Егор \| rogedkone](/users/cksrdp47d3308261ijuq7wfrxdl)                | 3       | 0       |
| [Roman \| Roman43](/users/ckur2qtt64721431xoboyjcte52)                 | 2       | 0       |
| [Бут Игорь \| santiment](/users/ckttd9x20893951vmltb8t7sha)            | 1       | 0       |

**Доношу простую мысль: успех — это не магия, это осознанная системная работа и кайф от роста.**
Мои менти выводят решения в продакшн, пробиваются в лидеры рейтингов — кому не хочется быть в такой команде?

---

## Почему я?

- **Прокачаю проект** — от TDD архитектуры до культурного CI/CD
- **Вдохновлю команду** — и научу мыслить по‑новому, где ИИ — напарник, а не угроза
- **Выращу мидлов и сеньоров** — доказано платформой и рейтингами моих учеников

**Сила — в сообществе, а техника — это просто смазка для ваших побед. Присоединяйтесь!**

---

## Контакты

- 📧 [n.lanets@freecode.academy](mailto:n.lanets@freecode.academy)
- Телеграм: [@freecode_academy](https://t.me/freecode_academy)

---

**P.S.**: Мой опыт — ваш драйвер роста. Хотите в команду? Ищете менторство? Пишите. Растём вместе!