mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-1998: Problem when deleting with EntityManager->remove($entity) #2523
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Aug 28, 2012).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user vigor_bg:
The problem is when using EntityMamager->remove($entity). The Sql query generated doesn't convert the values of the ids according to the field type that is used in doc block annotation. After investigating I found that in Doctrine\DBAL\Connection the function delete doesn't support to receive as param the types of the ids to be given to the executeUpdate function which is called in it and supports them. (The types need to be provided from the persisters from which the delete is called).
I hope it make sense to you. I got that problem because I am using custom time stamp column type as id. And it converts the value of the field to time stamp string, which if not converted to the proper sql value is not recognised and the delete doesn't go trough.
As far as I can see it is something that was missed and hope it will be fixed soon.
If you have any questions please ask.
Also on request I can provide example code and the fix I have done for myself.
@doctrinebot commented on GitHub (Aug 28, 2012):
@doctrinebot commented on GitHub (Aug 29, 2012):
Comment created by @FabioBatSilva:
Hi Victor
Could you attach/paste your custom type and entity please ?
@doctrinebot commented on GitHub (Aug 30, 2012):
Comment created by vigor_bg:
Ok I have attached them. The EwtTimestamp is the custom type.
@doctrinebot commented on GitHub (Sep 17, 2012):
Comment created by @ocramius:
[~vigor_bg] do you have a failing test case for this one?
@doctrinebot commented on GitHub (Sep 17, 2012):
Comment created by vigor_bg:
Nope sorry haven't done any test cases for this one
@doctrinebot commented on GitHub (Sep 23, 2012):
Comment created by @FabioBatSilva:
Hi Victor,
I can't reproduce, could you change the added test case and try to make it fails ?
Thanks
@doctrinebot commented on GitHub (Sep 26, 2012):
Comment created by vigor_bg:
Sure will do it as soon as I can. Sorry I didn't answer sooner just was in a holiday :)
@doctrinebot commented on GitHub (Oct 2, 2012):
Comment created by @FabioBatSilva:
Thanks Victor
Please let me know when you change the test
@doctrinebot commented on GitHub (Oct 2, 2012):
Comment created by vigor_bg:
Sorry for the delay i have attached the test case (DDC1998Test1.php).
@doctrinebot commented on GitHub (Oct 10, 2012):
Comment created by @FabioBatSilva:
Hi Victor,
Sorry for the delay to answer
I think that we can't fix it,
Your type requires sql conversion to work, and doctrine does not support @Id fields with sql conversion.
@doctrinebot commented on GitHub (Oct 11, 2012):
Comment created by vigor_bg:
Really as far as i can see in the code you do convert them when you are executing an update. And the fix that i did for my self is to add 3rd parameter to the function delete in Doctrine\DBAL\Connection and then every where where it is called in the code which is in 2 places Doctrine\ORM\Persisters\BasicEntityPersister and Doctrine\ORM\JoinedSubclassPersister to give that parameter with the types. And as far as i can see you do that for the updates. After that in Connection delete you call the executeUpdate which supports the type and you just have to pass it along. And that is it.
@doctrinebot commented on GitHub (Jan 23, 2013):
Comment created by @ocramius:
Reducing priority. It is an edge case, and we already don't officially support custom object types as identifiers.
@doctrinebot commented on GitHub (May 1, 2013):
Comment created by @beberlei:
We should be able to support this I think, i don't see a reason it shouldnt work
@doctrinebot commented on GitHub (May 1, 2013):
Comment created by @beberlei:
Will be fixed in 2.4
@doctrinebot commented on GitHub (May 1, 2013):
Issue was closed with resolution "Fixed"