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

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

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

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

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

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

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

Я вижу пока только тот вариант, что описал — нужно наличие поля, в котором значения разделены запятой. Для этого лучше всего подходит эта технология: habrahabr.ru/post/253737/

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

Напомню, вот уже несколько месяцев тянется тема с поданным против меня иском от «Фабрики сайтов». Топики: раз, два и три. Так вот, вчера поступило Решение Арбитражного Суда об отказе в удовлетворении иска.. Таким образом судом официально признано, что мои суждения в отношении качества работы студии «Фабрика сайтов» являются правдивыми и аргументированными. Спасибо всем, кто поддерживал меня в этом инциденте! :) P.S. Еще позже отдельным топиком напишу по поводу особенностей работы «Фабрики сайтов». Не раз клиенты в комментариях в сети указывали на то, что у Фабрики зачастую присутствуют скрытые платежи и т.п. Сейчас по сути есть на это доказательства. Подробности опишу позже, но Фабрика вменяла мне упущенную выгоду по Предварительному Договору с заказчиком на сумму 240 000 рублей. Еще раз — двести сорок тысяч рублей. От меня приз первому, кто насчитает на их сайте услуг на 240 000 рублей :) Скажу так — я суммировал все их модули и т.п. — не получалось даже близко. UPD: резолюция. UPD 5: Отказ по апелляционной жалобе.

Пример запроса: $query = $modx->newQuery('modResource'); $query->select(array('modResource.id AS resourceId')); $query->innerJoin('modTemplateVarTemplate', 'TVValues', array('TVValues.contentid = modResource.id')); $query->where(array('TVValues.tmplvarid:=' => 8)); Получаем SQL со строкой '8', а не числом 8: SELECT modResource.id AS resourceId FROM modx_site_content AS modResource JOIN modx_site_tmplvar_templates TVValues ON TVValues.contentid = modResource.id WHERE TVValues.tmplvarid = '8' Проверил разные варианты. Вывод такой: xPDO не получает мета-информацию о присоединённых таблицах (хотя парсит их отлично). Поэтому, все поля этих таблиц он приводит к строковому типу. Как заставить xPDOQuery получать информацию о типах данных присоединяемых таблиц?