Denormalizing bidirectional ManyToOne relations don't remove items

[Drachenkaetzchen]

I have configured a bidirectional ManyToOne/OneToMany relation:

Owning side:
https://github.com/partkeepr/PartKeepr/blob/sf2migration/src/PartKeepr/ManufacturerBundle/Entity/Manufacturer.php#L82
Inversing side: https://github.com/partkeepr/PartKeepr/blob/sf2migration/src/PartKeepr/ManufacturerBundle/Entity/ManufacturerICLogo.php#L14

When I attempt to remove items, I get the proper response from DunglasApiBundle where the removed items don't exist anymore, however, the items still persist in the database. Most likely DunglasApiBundle doesn't call EntityMananger->remove for removed entities, although I'm not sure if Doctrine can be configured to take care of that automatically.

Note that this only seems to happen for bidirectional ManyToOne/OneToMany relations.

Here's the example request:

{
   "icLogos":[
      {
         "@id":"/~felicitus/PartKeepr/web/app_dev.php/api/manufacturer_i_c_logo/2/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"8a2a5eb9-908b-4bd7-aec3-be18dbecb298",
         "originalFilename":"actel.png",
         "mimetype":"image/png",
         "size":5003,
         "extension":"png"
      },
      {
         "@id":"/~felicitus/PartKeepr/web/app_dev.php/api/manufacturer_i_c_logo/378/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"c85ccde8-236f-11e5-be7f-f8b156bec77a",
         "originalFilename":"test.png",
         "mimetype":"image/jpeg",
         "size":114281,
         "extension":"png"
      },
      {
         "@id":"/~felicitus/PartKeepr/web/app_dev.php/api/manufacturer_i_c_logo/379/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"262d1aa4-2370-11e5-9f54-f8b156bec77a",
         "originalFilename":"kappe.png",
         "mimetype":"image/png",
         "size":37141,
         "extension":"png"
      }
   ]
}

Response:

{
   "@context":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/contexts\/Manufacturer",
   "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturers\/2",
   "@type":"Manufacturer",
   "name":"ACTEL2",
   "address":null,
   "url":"foo\/bar",
   "email":null,
   "comment":null,
   "phone":null,
   "fax":null,
   "icLogos":[
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/2\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"8a2a5eb9-908b-4bd7-aec3-be18dbecb298",
         "originalFilename":"actel.png",
         "mimetype":"image\/png",
         "size":5003,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/378\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"c85ccde8-236f-11e5-be7f-f8b156bec77a",
         "originalFilename":"test.png",
         "mimetype":"image\/jpeg",
         "size":114281,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/379\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"262d1aa4-2370-11e5-9f54-f8b156bec77a",
         "originalFilename":"kappe.png",
         "mimetype":"image\/png",
         "size":37141,
         "extension":"png"
      }
   ]
}

So the returned JSON is fine, but removals aren't stored in the database. Here's a GET on the same resource without any changes:

{
   "@context":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/contexts\/Manufacturer",
   "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturers\/2",
   "@type":"Manufacturer",
   "name":"ACTEL2",
   "address":null,
   "url":"foo\/bar",
   "email":null,
   "comment":null,
   "phone":null,
   "fax":null,
   "icLogos":[
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/2\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"8a2a5eb9-908b-4bd7-aec3-be18dbecb298",
         "originalFilename":"actel.png",
         "mimetype":"image\/png",
         "size":5003,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/378\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"c85ccde8-236f-11e5-be7f-f8b156bec77a",
         "originalFilename":"test.png",
         "mimetype":"image\/jpeg",
         "size":114281,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/379\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"262d1aa4-2370-11e5-9f54-f8b156bec77a",
         "originalFilename":"kappe.png",
         "mimetype":"image\/png",
         "size":37141,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/380\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"3c888720-2370-11e5-b867-f8b156bec77a",
         "originalFilename":"gw3ROhXR.jpg",
         "mimetype":"image\/jpeg",
         "size":32796,
         "extension":"jpeg"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/381\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"559e5b4a-2370-11e5-b92d-f8b156bec77a",
         "originalFilename":"gw3ROhXR.jpg",
         "mimetype":"image\/jpeg",
         "size":32796,
         "extension":"jpeg"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/382\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"6fb5577c-2370-11e5-9686-f8b156bec77a",
         "originalFilename":"Zahlungseingang2.png",
         "mimetype":"image\/png",
         "size":37431,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/383\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"f7b5cf4e-2370-11e5-b36c-f8b156bec77a",
         "originalFilename":"CD7w1-_UIAAldNn.jpg",
         "mimetype":"image\/jpeg",
         "size":119472,
         "extension":"jpeg"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/384\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"d9699fe0-2373-11e5-a018-f8b156bec77a",
         "originalFilename":"744px-Deutsche_Bahn_AG-Logo.svg.png",
         "mimetype":"image\/png",
         "size":18381,
         "extension":"png"
      },
      {
         "@id":"\/~felicitus\/PartKeepr\/web\/app_dev.php\/api\/manufacturer_i_c_logo\/385\/getImage",
         "@type":"ManufacturerICLogo",
         "type":"iclogo",
         "filename":"ee01989c-2376-11e5-88aa-f8b156bec77a",
         "originalFilename":"gw3ROhXR.jpg",
         "mimetype":"image\/jpeg",
         "size":32796,
         "extension":"jpeg"
      }
   ]
}

[dunglas]

Did you try to set cascade parameters on both side of the relation in Doctrine mappings?
Sounds more like a Doctrine bug than an ApiBundle one.

If it doesn't work using a custom Data Provider should do the trick.

[Drachenkaetzchen]

cascade delete on the ManufacturerICLogo should not be set, because it Doctrine tries to remove the the parent entity.

When I do a manual test, the relation gets removed properly:

$manufacturer = $this->getDoctrine()->getManager()->find("PartKeepr\\ManufacturerBundle\\Entity\\Manufacturer", 2);

$manufacturer->getIcLogos()->removeElement($manufacturer->getIcLogos()->first());

So I don't think it's a doctrine bug. For testing, I tried removing the association directly in ResourceController::putAction using removeElement, which also works fine.

When I simply overwrite the association with a simple array, no changes are committed into the database and that's exactly what the deserializer does:

$object->setIcLogos(array()); // Results in no changes

Noteworthy: Once a relation has been established, the collection is not an ArrayCollection but a PersistentCollection. Being not familar with the internals of Doctrine, I can only assume that it is essential to operate on the PersistentCollection once entities have established an association.

[dunglas]

The problem is related to Doctrine internals. I've opened a PR on PartKeepr with a workaround: partkeepr/PartKeepr#409. Let me know if you think it's OK to close this bug.

[Drachenkaetzchen]

Yes, that workaround works, but I'm not really sure why. Thank you!

I think we should document the adders/removers somehow, what do you think?

[dunglas]

We definitely should!

It works because when adders/removers are present the property isn't accessed directly. The PropertyAccess Component use those methods instead of the setter. That's why the PersistentCollection isn't overwritten by an array.
But in that case, I think it's achievable with a setter too. The main problem was that the reference is stored on the other side (in IcLogo::$manufacturer) and that side must be updated manually. Doctrine doesn't do it automatically.

[Drachenkaetzchen]

I'd like to keep this issue open as I might want to document the issue and/or provide a possible fix. As I go along migrating all entities, there might be more stuff that relies on the setter in some way.

Also, the blog-api demo should be updated to reflect that behavior.

[dunglas]

Is the blog-api demo impacted?

[Drachenkaetzchen]

No, but a ManyToOne/OneToMany example in the blog-api would be very nice to have as a sample implementation, especially with the current setter/adder/deleter issue.

Things I often miss with Symfony2 bundles in general that "full-featured" demos are rare which could be used as reference.

[dunglas]

Should be fixed now (not tested). Feel free to reopen is it's not the case.