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

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'ами, всё остальное — оставляем как есть.

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

JOIN

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.**: Мой опыт — ваш драйвер роста. Хотите в команду? Ищете менторство? Пишите. Растём вместе!