Added note about saving hooks differing from the underlying persistence layer ref #1526

Resources/doc/reference/saving_hooks.rst

@@ -1,12 +1,29 @@
 Saving hooks
 ============
 
-When the model is persisted upon on the stated object two Admin methods are
-always called. You can extend this method to add custom business logic.
+When a SonataAdmin is submitted for processing, two events are always called. One 
+is before any persistence layer interaction and the other is afterwards, the 
+events are named as follows:
 
-    - new object : ``prePersist($object)`` / ``postPersist($object)``
-    - edited object : ``preUpdate($object)`` / ``postUpdate($object)``
-    - deleted object : ``preRemove($object)`` / ``postRemove($object)``
+- new object : ``prePersist($object)`` / ``postPersist($object)``
+- edited object : ``preUpdate($object)`` / ``postUpdate($object)``
+- deleted object : ``preRemove($object)`` / ``postRemove($object)``
+
+It is worth noting that the update events are called whenever the Admin is successfully
+submitted, regardless of whether there are any actual persistence layer events. This 
+differs from the use of preUpdate and postUpdate events in DoctrineORM and perhaps some
+other persistence layers.
+
+For example: if you submit an edit form without changing any of the values on the form
+then there is nothing to change in the database and DoctrineORM would not fire the **Entity**
+class's own ``preUpdate`` and ``postUpdate`` events. However, your **Admin** class's 
+``preUpdate``  and  ``postUpdate`` methods *are* called and this can be used to your 
+advantage.
+
+.. note::
+
+    When embedding one Admin within another, for example using the ``sonata_type_admin``
+    field type, the child Admin's hooks are **not** fired.
 
 
 Example used with the FOS/UserBundle