ну, иными словами, цель я понял. я смысла не понял)

Мне нужно перечислить все пары с их ид. Потом результаты занесутся в таблицу dublicates

Проще будет пройтись по всем записям в таблице и пытаться найти совпадения - 1 запрос за раз

По-моему без full outer join тут не обойтись, хотя я могу ошибаться.

найти юзеров, которые в автобусе будут отзываться на одно и то же имя?

Найти юзеров, который по какому-то долбоебическому стечению обстоятельств, ввели свое имя неверно (и таких много). Специфика проекта такова, что пользователи регистрируются без введения email и пароля. Точнее email вводится, но он не уникален. Другими словами, они могут регистрироваться сколь угодно много раз

Найти юзеров, который по какому-то долбоебическому стечению обстоятельств, ввели свое имя неверно (и таких много). Специфика проекта такова, что пользователи регистрируются без введения email и пароля. Точнее email вводится, но он не уникален. Другими словами, они могут регистрироваться сколь угодно много раз

лучше ngram, а не soundex

лучше ngram, а не soundex

Не знаю что это такое, но обязательно посмотрю

самый нормальный способ искать с опечатками

3граммы самое оно

самый нормальный способ искать с опечатками

Он завязан на языке?

я делал его и в бд и в языке и в postgresql есть экстеншн

elasticsearch/sphinx умеют

в твоем случае еще надо outliers отсечь

т.е. сортировать и взять диапазон, а не все сравнивать со всеми

Короче, вот результат, если кому интересно: SELECT c.id, c.firstname, c.lastname, d.id, d.firstname, d.lastname FROM consumer c JOIN consumer d ON ( (c.firstname = d.firstname AND c.lastname = d.lastname) OR # Equal (soundex(c.firstname) = soundex(d.firstname) AND soundex(c.lastname) = soundex(d.lastname)) # Soundex (c.firstname LIKE CONCAT('%', d.firstname, '%') AND c.lastname LIKE CONCAT('%', d.firstname, '%')) OR (d.firstname LIKE CONCAT('%', c.firstname, '%') AND d.lastname LIKE CONCAT('%', c.firstname, '%')) ) AND (c.id < d.id) Всего 6200 строк. Запрос выполняется в течение 15 секунд

6200 это количество строк в таблице users ?

6200 это количество строк в таблице users ?

да, таблица называется consumer на самом деле

да, не тем местом читаю sql. После добавления нового пользователя в базу будешь заново гонять запрос?

да, не тем местом читаю sql. После добавления нового пользователя в базу будешь заново гонять запрос?

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

Всем доброго времени суток) Кто использовал генерацию миграций и Postgis в symfony? Есть проблема связана с генерацией миграции которая пытается дропнуть таблицы postgis'a. Или может есть что-то вроде конфига schema_filter который бы заставил всю эту историю смотреть только в схему public?

Всем доброго времени суток) Кто использовал генерацию миграций и Postgis в symfony? Есть проблема связана с генерацией миграции которая пытается дропнуть таблицы postgis'a. Или может есть что-то вроде конфига schema_filter который бы заставил всю эту историю смотреть только в схему public?

Так в чем проблема

Так в чем проблема

Команда генерации миграции создает запросы на дроп таблиц и прочего связанного с postgis, а этого не нужно

Команда генерации миграции создает запросы на дроп таблиц и прочего связанного с postgis, а этого не нужно

Причем тут таблицы и постгис

Таблицы это таблицв

Причем тут таблицы и постгис

он за diff команду

Ну вообще в доктрине scheme_filter есть

Ну вообще в доктрине scheme_filter есть

он только к таблицам относится

он только к таблицам относится

все. туплю оО

все. туплю оО

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

Ребят, а у меня вопрос по доктрине. Есть у меня сущность А, у неё куча связей и через 7 или 8 сушностей у неё есть связь, скажем, с сущностью Z. И мне нужно посчитать сколько Z привязано к сущности А. Если идти по всем связям - запросов будет куча. Правильно ли я понимаю, что я могу создать простой класс B, который не привязан к таблице в базе и с помощью result set mapping и sql запроса, который считает количество этих Z, спроецировать результат запроса на инстанс этого класса?

Ребят, а у меня вопрос по доктрине. Есть у меня сущность А, у неё куча связей и через 7 или 8 сушностей у неё есть связь, скажем, с сущностью Z. И мне нужно посчитать сколько Z привязано к сущности А. Если идти по всем связям - запросов будет куча. Правильно ли я понимаю, что я могу создать простой класс B, который не привязан к таблице в базе и с помощью result set mapping и sql запроса, который считает количество этих Z, спроецировать результат запроса на инстанс этого класса?

Да, ты можешь сделать обычный sql запрос а результаты замапить на сущность. Но это не самый легкий вариант. Лучше сделать DQL запрос

Да, ты можешь сделать обычный sql запрос а результаты замапить на сущность. Но это не самый легкий вариант. Лучше сделать DQL запрос

На сущность или на инстанс произвольного класса?

На сущность или на инстанс произвольного класса?

Насколько я знаю ты мапишь на сущность, и даже на ее связи

Да, ты можешь сделать обычный sql запрос а результаты замапить на сущность. Но это не самый легкий вариант. Лучше сделать DQL запрос

ой да там не сложно)

ой да там не сложно)

Объясни тогда человеку, че сидишь?)

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

Которое обычно будет null

не обязательно, ты всегда можешь сделать что-то типа

Но при запросе через result set mapping - оно будет заполняться?

SELECT COUNT(entity.id) FROM Foo\Foo entity INNER JOIN Foo\Bar bar WITH bar.id=entity.someId

единственное ограничение в DQL в плане джойнов - можешь только с сущностями работать и джойнить только сущности

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

да, можешь

О, супер)

Спасибо)

можешь даже так: SELECT new SomeDTO(COUNT(entity.id))

ну то есть либо так либо руками массивчик на объект

увы result set mapping тоже только сущности пока умеет

единственное ограничение в DQL в плане джойнов - можешь только с сущностями работать и джойнить только сущности

А еще в результирующем массиве могут быть сущности разных типов, так что если через foreach перебираешь их, можно обломаться

но! всегда можно написать свой гидратор!)))

А еще в результирующем массиве могут быть сущности разных типов, так что если через foreach перебираешь их, можно обломаться

хочешь хорошо - делай хорошо)

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

но! всегда можно написать свой гидратор!)))

Всегда можно написать и свою доктрину)

Всегда можно написать и свою доктрину)

это на пару порядков задачка посложнее

но да, можно)

особенно если без DQL

можно в разы проще сделать

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

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

Вот это поворот

Вот это поворот

Шучу

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

Ну мало ли, вдруг им нужна какая-то мета, хз ещё какие там ограничения внутри

Ну мало ли, вдруг им нужна какая-то мета, хз ещё какие там ограничения внутри

Вот вчера только такой запрос делал

Но тут таблица genre мапится на сущность Genre

Ну, или наоборот, не суть

ERROR: S client not available

Но тут таблица genre мапится на сущность Genre

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

Или не надо?

Если не сложно)

Я с телефона, в транспорте, у меня сейчас никак(

Если не сложно)

Не, нельзя

Грусть

Так пробуй

можешь даже так: SELECT new SomeDTO(COUNT(entity.id))

Грусть

Еще раз, почему ты не хочешь делать DQL запрос?

Но тут таблица genre мапится на сущность Genre

ну так в чем проблема? все что ты описал спокойно делается через DQL

DQL, который вернёт массивчик?

DQL, который вернёт массивчик?

DQL это тоже самое, что сделать SQL и замапить результат на сущность, только процесс автоматический

Очень редко, когда надо маппить результаты на сущности, только когда у тебя там какие-нибудь хитросплетения

Очень редко, когда надо маппить результаты на сущности, только когда у тебя там какие-нибудь хитросплетения

Их есть у меня

Их есть у меня

Может тебе это только кажется?

Ты ж даже не знаешь, что такое DQL

Или знаешь?

Язык запросов доктрины же

Больше контекста в вопросе не помешало бы)

Язык запросов доктрины же

Ну по сути DQL запрос конвертируется в обычный SQL запрос, а результаты этого запроса потом маппятся на сущности, то же, что хочешь сделать и ты. DQL обычно хватает для большинства нужд, но ты говоришь, что у тебя там дерзкие запросы?)

Больше контекста в вопросе не помешало бы)

Опиши свои сущности и связи между ними, можешь сделать скрины, я так больше люблю) Скинь мне, скажи, что тебе надо, я напишу DQL запрос

Можешь в личку если хочешь

Ну по сути DQL запрос конвертируется в обычный SQL запрос, а результаты этого запроса потом маппятся на сущности, то же, что хочешь сделать и ты. DQL обычно хватает для большинства нужд, но ты говоришь, что у тебя там дерзкие запросы?)

Под словом "хитросплетения" ты имел в виду сложность запросов или размазанность и запутанность бизнес-логики?

Или нечто третье?

Под словом "хитросплетения" ты имел в виду сложность запросов или размазанность и запутанность бизнес-логики?

Сложность запросов. Бывает ты используешь какие-то специфические для данной БД конструкции или функции, который никак не используешь в DQL. Тогда можно сделать SQL запрос и получить данные в виде массива, либо можно сделать nativeQuery и указать правила гидрации твоих сущностей. В обоих случаях, ты привязываешь свои запросы под конкретную БД, так что в будущем, если сменишь ее, все может сломаться

Тут дай бог с 5.5.9 на 5.7 переехать, чтоб хотя бы json уметь. Куда уж там до смены базы)

Тут дай бог с 5.5.9 на 5.7 переехать, чтоб хотя бы json уметь. Куда уж там до смены базы)

Доктрина не работает с мускульным json'ом

Доктрина не работает с мускульным json'ом

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

Или тип)

Да и хрен с ней, с доктриной) надо было пару раз восстановить из таблицы логов в json кой-чо

Тот ещё треш с replace