Пустые отношения при сериализации с JMSSerializer - PullRequest
Новая
       40

Пустые отношения при сериализации с JMSSerializer

0 голосов
/ 04 мая 2018

У меня проблемы с написанием действия контроллера внутри проекта Symfony, который должен возвращать данные (в данном случае это заказы интернет-магазина). Да ... Это своего рода REST-API. Этот маршрут просто вызывается из некоторого JavaScript. И данные должны быть визуализированы на стороне клиента.

Проблема:

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

Это пример вывода: 

orders: [
  {
    id: 2,
    created: '2016-05-04T11:40:27+00:00',
    user: {},
  }
]

Когда я делаю что-то вроде 

$orders = $this->getDoctrine()->getRepository('AppBundle:Order')
  ->findAllCompleted();

$serializationContext->setSerializeNull(true);
$serializationContext->setGroups(['statistics']);

$json = $serializer->serialize($orders, 'json', $serializationContext);
$response = new Response($json, $statusCode, [
  'Content-Type' => 'application/json',
]);

return $response;

... я получаю хороший JSON-ответ от сервера, но каждый связанный объект каждого заказа, например, скажем, user, равен {} (пусто).

Даже если я дам дамп связанной сущности до ее сериализации следующим образом: 

[...]
$myOrder = array_filter($orders, function($order) {
  if ($order->getId() == 2) {
    return true;
  }
  return false;
});

dump($myOrder[0]->getUser());
die();

... это приводит к пустой (не гидратированной) сущности.

Но если я изменю этот код отладки на: 

$myOrder = array_filter($orders, function($order) {
  if ($order->getId() == 2) {
    return true;
  }
  return false;
});

dump($myOrder[0]->getUser()->getUsername());
die();

... Я получаю чистый вывод (строку) со значением имени пользователя этой сущности.

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

Как я могу заставить JMSSerializer позаботиться о увлажнении этих связанных объектов?

Я не нашел никаких подсказок в документах ...

Кстати, это конфиги сущности JMS порядка и пользователя. 

AppBundle\Entity\User:
  exclusion_policy: ALL
  properties:
    userMeta:
      expose: true
    address:
      expose: true
    username:
      expose: true
    email:
      expose: true
    isReseller:
      expose: true
    acceptPublicOrders:
      expose: true
    vatNumber:
      expose: true
    taxRate:
      expose: true


AppBundle\Entity\Order:
  exclusion_policy: NONE
  properties:
    id:
      groups: ['statistics']

    user:
      groups: ['statistics']

    configuration:
      groups: ['statistics']

    created:
      groups: ['statistics']

    invoiceItems:
      groups: ['statistics']
      exclude: true

1 Ответ

0 голосов
/ 04 мая 2018

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

@ ManyToOne (targetEntity = "Корзина", каскад = {"все"}, fetch = "EAGER")

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

свалка ($ myOrder [0] -> GetUser () -> GetUserName ());

https://www.doctrine -project.org / проекты / Доктрина-ОРМ / о / последняя / ссылка / аннотации-reference.html # annref-onetoone

Или это, если вы используете DQL
14.7.6.6. Временно изменить режим выборки в DQL

http://doctrine -orm.readthedocs.io / ен / последний / ссылка / DQL-доктрина-запрос-language.html # временно-переключающий-режим-в-DQL выборки

Редактировать: я был не прав Я сделал несколько тестов, все работало нормально с отложенной загрузкой или с нетерпением, пока я не попробовал с группами, даже если поля выставлены, вы не используете группу по умолчанию, поэтому она принимает только те вещи, на которых есть группа «статистика» Попробуйте добавить группу по умолчанию здесь

$ serializationContext-> setGroups ([ 'по умолчанию', 'Статистика']);

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

...