Пользовательский объект в отношениях «один к одному» с использованием первичного ключа, совместно используемого с внешним ключом

Question

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

У меня есть сущность (Пользователь), которая используется в качестве пользовательского класса в моем приложении, тогда у меня есть другой объект (UserExtra) в отношениях «один к одному» с пользовательским объектом, идентификатор UserExtra такой же, как Пользователь. Внешний ключ такой же, как и первичный ключ.

Когда пользовательский объект загружен (скажем, $this->getUser() или {{ app.user }}, данные UserExtra также загружаются через соединение. Вся суть имеет два объекта, поэтому мне не нужно сразу загружать все данные.

Я даже попытался определить пользовательский репозиторий UserLoaderInterface/UserProviderInterface для пользователя, убедившись, что refreshUser и loadUserByUsername будут загружать только пользовательские данные (я бы хотел, чтобы данные UserExtra сидели в прокси-сервере, если я им явно не нужен), но когда Doctrine отправляется на Hydrate объект, он выдает дополнительный запрос для загрузки данных UserExtra, тем самым пропуская статус прокси.

Is есть выход из этого?

Answer 1

Есть много решения для Вашего вопроса:

1) Изменения стороны Обладание и обратной стороны http://developer.happyr.com/choose-owning-side-in-onetoone-relation - Я не думаю, что это правильно с точки зрения дизайна БДА каждый раз.

2) В таких функциях, как find, findAll и т. Д., Обратная сторона в OneToOne соединена автоматически (это всегда как выбор EAGER). Но в DQL он не работает, как Fetch EAGER, и это требует дополнительных запросов. Возможное решение - каждый раз присоединяться к обратному объекту

3) Если для некоторых прецедентов достаточно альтернативного формата результата (т. Е. getArrayResult()), это также может избежать этой проблемы.

4) Изменить обратную сторону, чтобы быть OneToMany - просто выглядит неправильно, возможно, может быть временным обходным решением.

5) Принудительные частичные объекты. Никаких дополнительных запросов, но также и без ленивой загрузки: $query->setHint (Query::HINT_FORCE_PARTIAL_LOAD, true) - швы мне единственное возможное решение, но не без цены: Частичные объекты немного рискованны, потому что поведение вашей сущности ненормально. Например, если вы не указали в ->select() все ассоциации, в которых вы пользователь, у вас может быть ошибка, потому что ваш объект не будет заполнен, все неконкретно выбранные ассоциации будут иметь значение

6) Не сопоставление обратной двунаправленной ассоциации OneToOne и либо использовать явное или услугу более активного записи подход - https://github.com/doctrine/doctrine2/pull/970#issuecomment-38383961 - и, похоже, доктрина закрыл вопрос

этот вопрос может помочь вам: one to one relation load