Доктрина 2.4 не может сохраняться / вставлять многие во многие объекты ассоциации

Question

Люди, вы можете мне помочь? У меня возникают проблемы с сохранением сущности (Solicitud) в Doctrine 2.4, у сущности все связанные с ней объекты уже хранятся в ее свойствах, когда я передаю объект менеджеру сущностей для сохранения и сброса.

Полностью описанные отношения должны быть...

1. Usuario-> Осторожности (один ко многим)
2. Solicitud-> Servicios (многие ко многим)
3. Категория-> Servicios (один ко многим)

Я сгенерировал сущности и структуру БД из моего XML Mapping...

В моем "solicitud" XML я определил отношение, как вы можете видеть ниже... и промежуточная таблица была эффективно создана, когда я выполнил команду:

vendor\bin\doctrine orm:schema-tool:update --force

с двумя колонками и все ок.

это на "Solicitud" на полях, которые определяют отношение многих ко многим

<many-to-many field="servicios" target-entity="Servicio">
<cascade>
<cascade-persist/>
</cascade>
<join-table name="solicitud_servicio">
<join-columns>
<join-column name="id_solicitud" referenced-column-name="id"/>
</join-columns>
<inverse-join-columns>
<join-column name="id_servicio" referenced-column-name="id"/>
</inverse-join-columns>
</join-table>

и это на Servicio

<doctrine-mapping xmlns="http://doctrine-project.org..." 
  xmlns:xsi="http://www.w3.org/2001/XMLS..." 
  xsi:schemalocation="http://doctrine-project.org... http://doctrine-
  project.org...">
  <entity name="Servicio" table="servicio">
  <indexes>
  <index name="id_categoria" columns="id_categoria"/>
  </indexes>
  <id name="id" type="integer" column="id">
  <generator strategy="IDENTITY"/>
  </id>
   <field name="codigo" type="string" column="codigo" length="15" 
  nullable="false"/>
  <field name="nombre" type="string" column="nombre" length="70" 
  nullable="false"/>
  <field name="detalle" type="string" column="detalle" length="250" 
  nullable="false"/>
  <field name="precioPublico" type="integer" column="precio_publico" 
  nullable="false"/>
 <field name="precioPrivado" type="integer" column="precio_privado" 
  nullable="false"/>
  <field name="medida" type="string" column="medida" length="15" 
  nullable="false"/>
  <field name="planificacion" type="integer" column="planificacion" 
  nullable="false"/>
  <field name="fabricacion" type="integer" column="fabricacion" 
  nullable="false"/>
  <field name="fechaCreacion" type="datetime" column="fecha_creacion" 
  nullable="true"/>
  <field name="ultimaModificacion" type="datetime" column="ultima_modificacion" 
  nullable="false"/>
  <many-to-one field="idCategoria" target-entity="Categoria">
  <join-columns>
  <join-column name="id_categoria" referenced-column-name="id"/>
  </join-columns>
  </many-to-one>
  </entity>
</doctrine-mapping>

Есть что-то, чего мне не хватает? может быть, другое предложение, призывающее к сохранению на другом из участвующих / связанных классов?

я пытаюсь упорствовать через сущность "solicitud" в предложениях менеджера сущностей... у меня они разделены на другом уровне, как DAO, но это не проблема, когда данные поступают на этот уровень, я пробовал var_dump, и все хорошо.

в моем "SolicitudService" я написал эту функцию, чтобы собрать все связанные объекты, необходимые для сохранения, я использую VO (виртуальные объекты) с функциями внутри для построения данных из объекта в Json или из Json в Objects и ToEntity Pattern(из VO в Object нужного класса).

что я делаю в этой функции:

1. Сначала я нахожу объекты, которые у меня есть в моем SolicitudServicioVO. В следующих трех предложениях после попытки я создаю новый объект Solicitud.
2. Затем я устанавливаю объекты, созданные с помощью сущностей DAO, в новый объект "Solicitud" (через 5 строк после комментария "//set Solicitud Properties").
3. После этого я повторяю ($solicitudServicioVO->listadoServicio) через listadoServicio (список сервисов, поступающих из внешнего интерфейса) и создаю VO для каждого, которые в следующих предложениях могут построить себя как сущность "или класс нужного типа ", в данном случае те, которые я упомянул в определении отношений в начале этого вопроса.

4. я посылаю, чтобы упорствовать в этом предложении

   $this->solicitudDAO->create($solicitud);
   

что приводит к DAO, который имеет...

function create($solicitud){
  $this->em->persist($solicitud);
  $this->em->flush();
  return $solicitud;
}

Эта функция может быть более описательной для ее имени, возможно, вызывая ее createSolicitud, поскольку ее целью является создание новой, но не имеет значения... она также должна добавить Solicitud, относящуюся к пользователю... так что я настаиваю, не обращайте на это внимания сейчас,

function addSolicitud($solicitudServicioVO){
try{
  $usuario = $this->usuarioDAO->find($solicitudServicioVO->getIdUsuario()->id);
  $direccion = $this->direccionDAO->find($solicitudServicioVO-
  >getIdDireccion()->id);
  $facturacion = $this->datoFacturacionDAO->find($solicitudServicioVO-
  >getIdFacturacion()->id);

  $solicitud = new Solicitud();

  //set Solicitud Properties
  $solicitud->setFechaCreacion(new DateTime());
  $solicitud->setEstado("solicitado");
  $solicitud->setIdFacturacion($facturacion);
  $solicitud->setIdDireccion($direccion);
  $solicitud->setIdUsuario($usuario);

  foreach($solicitudServicioVO->listadoServicio as $servicioVO)
  { 
    $categoriaServicioVO = $this->categoriaService->getCategoria($servicioVO-
    >getCategoriaId());
    $servicio = $servicioVO->toEntity();
    $servicio->setIdCategoria($categoriaServicioVO->toEntity());
    $solicitud->addServicio($servicio);
  }

  $resp = $this->solicitudDAO->create($solicitud);
  $response = Utils::getInstancia()->httpResponseSuccess('001');
  $response['data'] = $resp;
  return $response; 
  }
  catch(Exception $e){
  $response = $e->getMessage();
  }
}

Итак, я был наиболее описательным, что я мог, я не был в состоянии сохранить эти данные об объекте SOlicitud... есть ли у кого-то уже похожая проблема или какие-либо дополнительные идеи... может быть, в определении XML? через сущности в виде аннотаций, и нет ничего плохого.

Пожалуйста, помогите мне, это много-много рака принимал почти неделю без разрешения jajaja

Answer 1

Обновление статуса неисправности

"Новый объект был найден через отношение" Solicitud#servicios ", которое не было настроено для каскадного сохранения операций для объекта: Servicio@00000000044008fd0000000000ad7488. Чтобы решить эту проблему: либо явным образом вызовите EntityManager#persist() для этого неизвестного объекта, либо настройте каскадное сохранение эта связь в сопоставлении, например, @ManyToOne(..,cascade={\"persist\"}). Если вы не можете выяснить, какая сущность вызывает проблему, реализуйте

по сути, объект Solicitud является новым, потому что я пытаюсь его создать, данные для создания этого нового Solicitud отправляются из внешнего интерфейса с сервисами, которые я уже извлек из DB... я думаю, что я собираюсь решить Это.

Что вы думаете об этом цикле..., я должен просить найти для каждой службы, так как у меня есть соответствующий идентификатор?

    foreach($solicitudServicioVO->listadoServicio as $servicioVO)
    {   
        $categoria = $this->categoriaDAO->find($servicioVO->getCategoriaId());
        //maybe change this next line
        $servicio = $servicioVO->toEntity(); 
        // for this next one?? ill try and tell you...
        $servicio = $this->servicioDAO->find($servicioVO->getId());
        $servicio->setIdCategoria($categoria);
        $solicitud->getServicios();
        $solicitud->addServicio($servicio);

    }

как я показываю здесь, у меня есть служебные данные внутри $servicioVO, может быть, я смогу найти их в БД, в этом же цикле.

когда я выполняю Solicitud-> addServicio($servicio), я добавляю одну из этих отправленных служб внешнего интерфейса (servicio), которые могут конструировать себя как объект класса Servicio, в функции шаблона toEntity.

Итак, я понимаю, что доктрина может жаловаться, потому что она думает, что сервисы, добавленные в arrayCollection, не совпадают с тем, что он уже знает из своей БД, хотя я устанавливаю их с соответствующим ID, потому что сообщение об ошибке направляет меня больше для проверки обслуживающий объект... чем новый Solicitud.

... я решил эту проблему, сейчас я проверяю ее, и она отлично работает, так что... если кто-то еще упадет в эту яму, не доверяйте своим собственным построенным объектам, джаджая, доктрина хочет этого, и вы должны подчиняйся, найди или найди, чтобы получить нужные объекты вместо того, чтобы строить их, даже если данные внутри одинаковы, функция persist запуталась, в этой ситуации лучше использовать объекты db с прямым запросом.