sonata-project/EntityAuditBundle

Revision is created even if all changes to entities are ignored by global_ignore_columns

soerenbernstein opened this issue · 5 comments

Q A
Bug report? yes
Feature request? no
BC Break report? no

Tested version: 1.0.0, 1.0.4

EntityAudit is creating a new entry in the revisions table even though all changes to the entities are dismissed by global_ignore_columns config and no entry in the corresponding audit table is created. This results in an empty revision as in a revision with no changed entities.

So, after some digging, here is what I found:

  1. In LogRevisionListener::onFlush all entities scheduled for update are added to the extraUpdates array without even checking if this entity will in fact create a new audit entry.
  2. The new entry in the revision table will be created on the first call of LogRevisionListener::getRevisionId. This will method is called in LogRevisionListener::saveRevisionEntityData and in LogRevisionListener::postFlush.
  3. LogRevisionListener::postFlush is trying to update all entities from extraUpdates - why I don't know. It ignores the global_ignore_columns and the fact, that there might not be a new audit entry for the entity or a new revision. During this attempt it will create a revision even if there are no tracked changes.

Things I've tried so far that worked for me (kind of):

  1. Not adding the entities to the extraUpdates or adding them in the LogRevisionListener::saveRevisionEntityData. I don't understand the reason for the extraUpdates, so this might have bad effects in some cases.
  2. In LogRevisionListener::postUpdate skip all fields that are in the global_ignore_columns config. Worked, but seems a little to complicated.

A good solution probably would let LogRevisionListener::postFlush recognize that there is no new revision created so there is no need to update any entities from extraUpdates.

Updated the description

Still doesn't work in 1.0.6. Fix would be appreciated.

Is this issue a duplicate of #258?

no, still present in 1.0.9.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.