<commit_before>How Auditing Works
==================

Triggers are created for every database table for every entity and joinEntity configured for zf-doctrine-audit.  
Using triggers allows database modifications to be made anytime a change is made to the database whether through the ORM
or through a console connection, etc.  These triggers are created on the target database.  

When a change happens on the target database to a record configured to be audited an audit record is created.  
Each target table has a RevisionEntity table in the audit database which is a copy of the target table with a new field added
called ``revisionEntity_id``.  This is a foreign key to the RevisionEntity_Audit table.  The RevisionEntity_Audit table works like a receipt
for each set of changes to a row of audited data.  


Disambiguating RevisionEntity
-----------------------------

There are two distinct object which share the same name.  For every entity you audit there is a table which stores the entity data at the time an audit occurs.  There are usually many of these tables and the data they store are called "Revision Entity" data.  

There is also a RevisionEntity Entity and this entity is referenced from every "Revision Entity" as ->getRevisionEntity().  The "Revision Entity" stores the data, the RevisionEntity Entity is like a receipt for an audit.  


"Revision Entity"
-----------------

These store the audit data for a revision.  To get the audit data use a ArraySerializable Interface:  ``$revisionEntity->getArrayCopy();``


RevisionEntity Entity
---------------------

This table is a reciept for the change audited in the audit database.  The RevisionEntity_Audit table is used by the 
``ZF\Doctrine\Audit\Entity\RevisioinEntity`` entity.  This entity has a relationship to ``ZF\Doctrine\Audit\Entity\RevisionType`` 
which defines the type of audit which took place, whether insert, update, delete, or epoch.  

Another relationship to ``ZF\Doctrine\Audit\Entity\TargetEntity`` defines which entity was acted upon.  The ``TargetEntity`` contains 
dynamic data populated by data-fixture.  This ``TargetEntity`` has a relationship to the ``ZF\Doctrine\Audit\Entity\AuditEntity`` which 
has information about the auditing entity.  

Finally the RevisionAudit has a relationship to the ``ZF\Doctrine\Audit\Entity\Revision`` entity.  This ``Revision`` entity groups 
``RevisionEntity`` records together into ORM ``flush();`` operations.  So if your object manager has three entities to persist or update 
when ``flush();`` is called there will be one ``RevisionEntity`` record for each managed entity and one ``Revision`` entity.  This design 
allows groups of related database changes to be saved via the audit record.<commit_msg>Update how_auditing_works.rst<commit_after>How Auditing Works
==================

Triggers are created for every database table for every entity and joinEntity configured for zf-doctrine-audit.  
Using triggers allows database modifications to be made anytime a change is made to the database whether through the ORM
or through a console connection, etc.  These triggers are created on the target database.  

When a change happens on the target database to a record configured to be audited an audit record is created.  
Each target table has a RevisionEntity table in the audit database which is a copy of the target table with a new field added
called ``revisionEntity_id``.  This is a foreign key to the RevisionEntity_Audit table.  The RevisionEntity_Audit table works like a receipt for each set of changes to a row of audited data.  


AuditEntity
-----------

This refers generically to any entity audited by this tool.  The namespace for any entity audited is ``ZF\Doctrine\Audit\AuditEntity``.
When an audit occurs the data for the audited entity is stored in its corresponding AuditEntity.


RevisionEntity Entity
---------------------

This table is a reciept for the change audited in the audit database.  The RevisionEntity_Audit table is used by the 
``ZF\Doctrine\Audit\Entity\RevisionEntity`` entity.  This entity has a relationship to ``ZF\Doctrine\Audit\Entity\RevisionType`` 
which defines the type of audit which took place, whether insert, update, delete, or epoch.  

Another relationship to ``ZF\Doctrine\Audit\Entity\TargetEntity`` defines which entity was acted upon.  The ``TargetEntity`` contains 
dynamic data populated by data-fixture.  This ``TargetEntity`` has a relationship to the ``ZF\Doctrine\Audit\Entity\AuditEntity`` which 
has information about the auditing entity.  

Finally the RevisionAudit has a relationship to the ``ZF\Doctrine\Audit\Entity\Revision`` entity.  This ``Revision`` entity groups 
``RevisionEntity`` records together into ORM ``flush();`` operations.  So if your object manager has three entities to persist or update 
when ``flush();`` is called there will be one ``RevisionEntity`` record for each managed entity and one ``Revision`` entity.  This design 
allows groups of related database changes to be saved via the audit record.
{'fraction_non_alphanumeric': 0.07861822513400833, 'fraction_numerical': 0.0, 'mean_word_length': 4.193814432989691, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5143462', 'n_tokens_mistral': 1268, 'n_tokens_neox': 1222, 'n_words': 677}