Doctrine Tricks — SoftDelete

While pour­ing over some posts about Doc­trine I stum­bled upon a very nice solu­tion to the Cas­cad­ing Delete issue when using the Soft­Delete behav­iour on an Doc­trine Model. Here is what the guys at Elink Media writes;

I have been using Doc­trine ORM for a while now. Here I want to dis­cuss 2 tricky issues I have encoun­tered and resolved.

First, I’m para­noid of delet­ing records from the data­base. Things like reg­is­tered users, I would rather have them marked as “DELETED”, but still keep the record in the data­base, just in case …

With Doc­trine, the Soft­Delete behav­iour is per­fect for this pur­pose. When a model is enabled with the Soft­Delete behav­iour, an extra field “deleted_at” is auto­mat­i­cally added to the cor­re­spond­ing data­base table by default. So, when you call the delete() func­tion on a model object, the cor­re­spond­ing data row in the data­base receives a time­stamp on the “deleted_at” field. Data hav­ing val­ues on the “deleted_at” field will not be returned by any find meth­ods in the future.

It all sounds good, right? Not until you start try­ing to cas­cade “delete” on asso­ci­a­tions. Since we are not really delet­ing the record, DBMS level delete cas­cad­ing will sim­ply not work (In Doc­trine YAML schema term, the “onDelete: CASCADE” will not work). Now, I’ll illus­trate the prob­lem and the solu­tion with a typ­i­cal blog example.

Click for Solu­tion :-)

http://blog.elinkmedia.net.au/2010/01/30/doctrine-tricks/.

Leave a Comment

*

Get Adobe Flash playerPlugin by wpburn.com wordpress themes