треш будет когда придет заказчик и скажет "у нас чот там бэкенд тормозит и по 3 секунды запрос не отдается"

могу. но оно стоит того или не стоит?

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

ну да сейчас как раз фикстуры и пишу

треш будет когда придет заказчик и скажет "у нас чот там бэкенд тормозит и по 3 секунды запрос не отдается"

нагрузочные тесты тебя спасут) могу тебе сказать что "пара десятков миллионов записей в pivot таблице" это незначительно влияет на производительность. Проблемы начинаются с миллиардами (ну и еще все упирается в твою СУБД)

я до миллиардов пока не дорос потому тут ничего сказать не могу(

да, я планировал сиджем протестить

да, я планировал сиджем протестить

Вопрос. А отдавать на фронт по сколько записей планируется? По 100-200 или сразу лямы? Если юзать доктрину (а я думаю, что она есть тк это symfony), то лучше не маппить данные на сущности, а сразу отдать фронту. Это имеет смысл если нужно отдать много товаров. Часто натыкался на то, что разрабы тратят время на оптимизацию запросов/индексов и забывают, что с таким количеством сущностей с доктриной не удобно работать.

ну, лимит на запросы к спискам до 100 пока.

тогда не парься)

мы просто часто выборки делаем без лимитов, такая специфика )

ок понял )

Вопрос. А отдавать на фронт по сколько записей планируется? По 100-200 или сразу лямы? Если юзать доктрину (а я думаю, что она есть тк это symfony), то лучше не маппить данные на сущности, а сразу отдать фронту. Это имеет смысл если нужно отдать много товаров. Часто натыкался на то, что разрабы тратят время на оптимизацию запросов/индексов и забывают, что с таким количеством сущностей с доктриной не удобно работать.

поддержу на тему того что бы гидрировать на DTO напрямую для фронта

но у меня вообще особое к этому отношение)

вообще я сейчас как раз к этому подошел

есть некоторый набор, полей типа, которые не хочется светить наружу выплевывая сразу сущность

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

хотя вроде какой то другой механизм как мне кажется есть

Я помню в детстве winrar юзал ))))00

у меня винрар

решил я тут создать свой констрэйнт, начал делать как описано тут: https://symfony.com/doc/current/validation/custom_constraint.html , но вот что-то не пойму, можно ли там создать такой констрэйнт, чтоб чекать сразу 2 поля формы (надо проверить в пароле вхождения из логина) или лучше для этого использовать коллбек констрэйнт?

решил я тут создать свой констрэйнт, начал делать как описано тут: https://symfony.com/doc/current/validation/custom_constraint.html , но вот что-то не пойму, можно ли там создать такой констрэйнт, чтоб чекать сразу 2 поля формы (надо проверить в пароле вхождения из логина) или лучше для этого использовать коллбек констрэйнт?

юзни колбэк констрейнт на уровне формы и все

юзни колбэк констрейнт на уровне формы и все

а если форм несколько с одними и теми же условиями?

Тогда делаешь как делал, но в таргет пишешь class и вешаешь на весь класс

http://symfony.com/blog/new-in-symfony-4-1-internationalized-routing

Тогда делаешь как делал, но в таргет пишешь class и вешаешь на весь класс

у констрейнта таргет чтоль есть?

хм

а, там же есть

спасибо

http://symfony.com/blog/new-in-symfony-4-1-internationalized-routing

А есть простой способ по доменам разбить?

Ya.ru - ru, ya.com - es , например

Через листенер знаю

А есть простой способ по доменам разбить?

да, по хостнеймам

Привет ребят. Подскажите пожалуйста, есть 2 таблицы One to One: 1) User (id,name,etc) 2) Address (id, user_id) Мне нужно подгрузить пользователей с их адресом, правильно ли я понимаю, что лениво их нельзя подгрузить? из-за http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/reference/limitations-and-known-issues.html#join-columns-with-non-primary-keys ?

просто отрендери {user.address}

и все)

они как раз подгрузятся лениво

я перебираю в логах вижу, что он создаёт select на каждый

У юзера поставил :@ORM\OneToOne(targetEntity="Address", mappedBy="user") У адреса поставил: @ORM\OneToOne(targetEntity="User", mappedBy="address")

или требуется ещё что-то?

юзни вот это

тебе не надо бидирекшинал

не думаю что ты из адреса будешь доставать пользователя когда-то

крч иди почитай bidirectional vs unidirectional

mappedBY vs inversedBy

или требуется ещё что-то?

Можно добавить аннотацию @JoinColumn()

Можно добавить аннотацию @JoinColumn()

он будет добавлять Inner join, чтобы одним селектом получал сразу пользователей и адрес

я перебираю в логах вижу, что он создаёт select на каждый

после этого не будет создавать отдельный select для каждого адреса user-а

сейчас прочитаю и попробую, спасибо

он будет добавлять Inner join, чтобы одним селектом получал сразу пользователей и адрес

JoinColumn прокси вернет

и не будет никакого джоина

* @ORM\OneToOne(targetEntity="Address") * @ORM\JoinColumn(name="id", referencedColumnName="user_id") Так нельзя же? Ключ же не primary?

* @ORM\OneToOne(targetEntity="Address") * @ORM\JoinColumn(name="id", referencedColumnName="user_id") Так нельзя же? Ключ же не primary?

* @ORM\JoinColumn(name="address_id", referencedColumnName="id")

Note that the @JoinColumn is not really necessary in this example, as the defaults would be the same.

и не будет никакого джоина

Да, кажется Вы правы

думаю, самый верный способ - создать кастомный query_builder в репозитории

эм, так я не понял. Попробовал как в доке, но тогда получаю экзепшен: Entity of type 'AppBundle\Entity\Address' for IDs id(0) was not found

Каким путём мне идти?

создать qeurybuilder и явно join сделать ?

думаю, самый верный способ - создать кастомный query_builder в репозитории

я не понимаю что он хочет. сделать маппинг правильный или уже вытащить юзеров с адресами одним запросом?

это две задачи

сначала делаем первое и потом второе)

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

тогда тебе надо запрос $em->createQieryBuilder()->select('u', 'a')->from(User:class, 'u') ->leftJoin('u.address', 'a')

ERROR: S client not available

А в енти указывать join?

А в енти указывать join?

не обязательно

по умолчанию там уже будет JoinColumn(name="address_id", referencedColumnName="id")

У пользователя указал /** * @ORM\OneToOne(targetEntity="Address") * @ORM\JoinColumn(name="user_id", referencedColumnName="id") */ и сделал leftjoin с u.address но всё так же Entity of type 'AppBundle\Entity\Address' for IDs id(0) was not found

Что я сделал не правильно?

У пользователя указал /** * @ORM\OneToOne(targetEntity="Address") * @ORM\JoinColumn(name="user_id", referencedColumnName="id") */ и сделал leftjoin с u.address но всё так же Entity of type 'AppBundle\Entity\Address' for IDs id(0) was not found

нет ли у вас пользователей в базе, где в поле address_id указан не null, а 0? то есть ссылается на не существующую запись в таблице адрес

Таблица пользователя вообще не имеет поля address, только адрес содержит id пользователя

так и должно быть)

Так одно лечим другое калечим

у меня до этого была ошибка с primary key

* @ORM\OneToOne(targetEntity="Address") * @ORM\JoinColumn(name="id", referencedColumnName="user_id") Так нельзя же? Ключ же не primary?

я про это

крч иди почитай bidirectional vs unidirectional

и в правду, прочитайте про это...

я думаю, вам стоило бы сделать так: 1) User (id,name,addres_id, etc) 2) Address (id, etc)

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

А ещё можно embeddable. Если не предполагается несколько адресов.

или, у вас уже есть таблица с данными и хотите мэпить в доктрину?

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

я про это

Для начала по проектированию бд хотя б основы почитай чтоб вопросов с примари не было

Есть схема бд с этими двумя сущностями?

Посмотреть как связи осуществлены

Феч игер

@tabuna, а у Вас user_id в таблице адресов - уникальное поле?

нет, не уникальное, всё должно быть обработано в ручную

нет, не уникальное, всё должно быть обработано в ручную

Это кто придумал?

Начальство дало

Зачем идам вообще возможность редактирования иметь?

нет, не уникальное, всё должно быть обработано в ручную

тогда можно поступить так: сделать связь не one-to-one, а one-to-many

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

тогда можно вот так сделать: User (id, name, addresses, etc), Address (id, user_id, etc)

Да блин, стойте

@urazymbetov а разве это не добавит кучу неудобств связанный с тем, что всегда придётся брать первый элемент?