Hi, I have onDelete=SET NULL on image of item

class StoreItem  extends IdentifiedEntity
{
    /**
     * @var Image|NULL
     * @ORM\ManyToOne(targetEntity="Image", fetch="EAGER", cascade={"all"})
     * @ORM\JoinColumn(name="image_id", referencedColumnName="id", nullable=true, onDelete="SET NULL")
     */
    private $image;
}

When I get Item, than delete Image and call persist on DAO (but only on DAO for Item) and than do findBy on Item DAO (again) there is still Image set.

This is probably because the onDelete construct is made on database level, so doctrine doesn't know about it, and give me entity from cache or somewhere.

Is there a way how to invalidate Item entity when deleting image, or how to say Doctrine, that I really want to do query on database? Cause after reload page, everything is fine, and image is not set in Item entity.

Thanks for help Ondra

This is probably because the onDelete construct is made on database level

Exactly.

You either have to flush it, or create some crutch. For example you could create a listener, that would reset the $image property, when the other side is deleted.

I could not flush it, cause when deleting image, I am in ImageFacade → ImageService, which has DAO created for Image entity and there is no connection to Item.

Listener is option, thanks for that idea.

And something other, better, easier…? :-) Like onDelete on Doctrine level, I guess, there isn't…

Well you could, for a change, use EntityManager in that service, like the documentation says.

Sadly no, I don't know about any option that would do the delete instantly. Either listener, or you'd have to flush to propagate the changes to DB and relations.

yeah, put the whole EM to service seems like bad idea for me. Service get so much power with it and than I am worry :) I prefer that service has dependency on other services and one DAO, specially created for that entity. Other entities she(it=service) can get from other services or thanks to → related DAO.

so Listener must do it

Thanks very much for help!


You must first log in to participate in this discussion