Answers.Body: <p>We wrote an extension a while back that anonymises contacts including entries in log tables. So you could anonymise the contact first and then delete them.</p>
  
  <p>As Xavier has mentioned, you will have to make sure the log_ tables will be created with the right engine (InnoDB). If you already have log tables, you can either drop them, or convert them yourself. Afaik this only is necessary when you use extended logging.</p>
  
  <p>Find more information on the extension <a href="https://github.com/systopia/de.systopia.anonymiser" rel="nofollow noreferrer">here</a> - we have not tested it 4.7 yet.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-23T17:03:07.357Z
Answers.LastActivityDate: 2018-01-23T17:03:07.357Z
Answers.UserDisplayName: Fabian
Answers.Body: <p>Just to be sure I understand you properly: this is about the right to erasure (a contact ask your organisation to remove any data about them), right?</p>
  
  <p>It's my understanding that indeed you should remove the data both from the live and the log table (as the later isn't a temporary backup but long term archive).</p>
  
  <p>I recall a discussion about changing the format of the archive tables (so the engine isn't ARCHIVE anymore). The impact on the size wasn't that bad for what I remember, so it might be an option.</p>
  
  <pre><code>ALTER TABLE my_table ENGINE = InnoDB
  </code></pre>
  
  <p>And the only one I can think of to be able to be compliant.</p>
  
  <p>I'd suggest you to check on a backup first, there is a ROW_FORMAT=COMPRESSED
  option, but it seems you need to tune your install a bit to benefit from it on a per table basis... and it might not be needed, based on the size of your installation.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-23T15:02:26.790Z
Answers.LastActivityDate: 2018-01-23T15:02:26.790Z
Answers.UserDisplayName: Xavier
Body: <p>With the new GDPR legislation taking effect in a matter on months, it dawns on me... how can we delete people permanently from the logging tables? My understanding is that the table types are a special archive type that don't allow for deletion of individual rows. </p>
  
  <p>Is that right?</p>
  
Tags: <database><logging><gdpr>
Title: Data Protection / GDPR - deleting from logging tables
ThreadText: # Data Protection / GDPR - deleting from logging tables
  
  (Asked by: username_0 on 2018-01-20)
  
  With the new GDPR legislation taking effect in a matter on months, it dawns on me... how can we delete people permanently from the logging tables? My understanding is that the table types are a special archive type that don't allow for deletion of individual rows.
  
  Is that right?
  
  **Tags:** database, logging, gdpr
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-01-23. Score: 3
  
  We wrote an extension a while back that anonymises contacts including entries in log tables. So you could anonymise the contact first and then delete them.
  
  As username_2 has mentioned, you will have to make sure the log\_ tables will be created with the right engine (InnoDB). If you already have log tables, you can either drop them, or convert them yourself. Afaik this only is necessary when you use extended logging.
  
  Find more information on the extension [here](https://github.com/systopia/de.systopia.anonymiser) - we have not tested it 4.7 yet.
  
  
  ---
  
  ### Answer by username_2 on 2018-01-23. Score: 3
  
  Just to be sure I understand you properly: this is about the right to erasure (a contact ask your organisation to remove any data about them), right?
  It's my understanding that indeed you should remove the data both from the live and the log table (as the later isn't a temporary backup but long term archive).
  I recall a discussion about changing the format of the archive tables (so the engine isn't ARCHIVE anymore). The impact on the size wasn't that bad for what I remember, so it might be an option.
  ALTER TABLE my_table ENGINE = InnoDB
  
  And the only one I can think of to be able to be compliant.
  I'd suggest you to check on a backup first, there is a ROW_FORMAT=COMPRESSED
  option, but it seems you need to tune your install a bit to benefit from it on a per table basis... and it might not be needed, based on the size of your installation.
  
  
  ---
  
  