Re: Database cleanup horde_histories

Michael J Rubinsky <[email protected]> Wed, 01 May 2019 15:52:35 +0000
Newsgroups gmane.comp.horde.user
Message-ID <20190501155235.Horde.Pp27wY9aJpiWOTRhk3oY3qw@tarn.theupstairsroom.com>
Quoting Jens Wahnes <[email protected]>:

> Philipp Faeustlin wrote:
>> Hi is there a way to clean up the horde_histories database table?
>>
>> It seem like entries in this table will never be removed. Not even  
>> if you remove a user per cli.
>>
>> Is this supposed to work like this or is there something wrong with  
>> my installation of Horde?
>
> I'm having the same problem of a ever growing horde_histories table  
> as well. I think this behaviour is intended. The problem with  
> deleting stuff from the horde_histories table is that there can be  
> entries there by deleted users that are still needed. For example,  
> there could be a shared calendar that user X added entries to  
> (especially if it's recurring event) that are relevant even after  
> X's account is deleted. If one were to delete the entries of user X  
> in horde_histories upon deleting their other data  
> (horde-remove-user-data), the event in the shared calendar could not  
> be displayed properly anymore.

The history data doesn't really have anything to do with the *display*  
of entries. If the entry in question still exists in the application's  
backend storage, the entry will display fine. In general, the history  
data is used for synchronization of things like ActiveSync clients on  
a mobile device, or *DAV clients. If you don't care about  
synchronization it is generally safe to delete this information. Even  
if you do care about synchronization, it would generally be safe to  
delete REALLY old entries - basically as long as any clients you care  
about have synchronized since the history event date, you should be  
fine.

Note that history data might have auditing value in your organization,  
so that is also something to keep in mind as well.



> One thing that I've done in the past is to change the "history_who"  
> field of entries from users long deleted to "-system-" to anonymize  
> those entries for reasons of data protection. That should allow old  
> entries to still be used to reconstruct entries in shared calendars,  
> but not to keep personal data of people to longer relevant.
>
> Another approach I've taken is to specifically delete old entries  
> from horde_histories (of users long deleted) that refer to IMP. I  
> don't know if there can be entries of the "IMP" kind relevant to  
> other users still existing done by deleted users (maybe when using  
> shared mail folders?). Still I would want to get rid of them,  
> because "IMP" entries are by far the largest in numbers in our  
> setup, plus it's not that upsetting after all when one is unable to  
> look up the history of and old email (with the email itself still  
> being stored on the mail server). So with a MySQL database, I used  
> something along the lines of
>
> DELETE FROM horde_histories USING horde_histories LEFT JOIN  
> horde_prefs on (history_who=horde_prefs.pref_uid AND  
> horde_prefs.pref_name='last_login' AND  
> horde_prefs.pref_scope='horde') WHERE horde_prefs.pref_uid IS NULL  
> AND object_uid like 'imp:%' AND history_ts < 1483225200
>
> to remove very old "IMP" entries in horde_histories. So far this has  
> been working well for me, but I wouldn't want to bet that this is  
> the way to go.
>
>
> Jens
> -- 
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: [email protected]



-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

-- 
Horde mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
(unnamed) (application/pgp-keys, 9.1 KB) - not displayed
signature.asc (application/pgp-signature, 821 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4

iQIcBAABAgAGBQJcycDDAAoJEJGSgkbRsxbbJdMP/jfoLSLYiOj7c3i8ubh/Icya
nAu2XWyNbUQ/8kl3g6k6CBu+EstizXBFSikILSqRV8Q9ZW71H/L+7zJ3V7pJ450M
HzQ2eFxsJ1ISVu7WNhQZLfSFzlZhpGlp2pouLylKRnkAwa1hfcdJ52XOeDIUf6/o
dNMTEAN63jfq74nxv8KROEonSSqQ5Gwb1hIFiSdVSgOurBxH4UNYeqZLvcwszUDJ
E8gOVJqEULZ+sAbZGgdaRh9UU7iQic9d5UAZoi5glR6ddLXh7ynNADf5DsYPJFil
4bvcJEA4wUIcYAP/5g3kC79Eb83DVbrWJkyTCuLDT1YU4RUOsNJr9nIFrJL9Krsy
S4A901kjzjimThIcGCVMRY2937wP2C3wLTImB0iOjXK7pZ6Ed2nJyyCBEsRQrNGZ
6eOALnn+AFLAzZBiwfJcqI+BeDW3Nf9NVQ0zXpBpDtZiX5vZtBVRN1SNmDkge9qF
jRzUGDCgsHQWiwPotCwXN+aJlUDMI4Ue+3VcLOn3meynZEkGlOlUW3OoiJBAe563
cRPvEeUILr+Z1i5CekuAhB5kvCot4PFzllHGDE/daI4HutHequkpG6joAyMCn0K9
jPdIuqNTukyWE0c7NFXT5/gQtHKiXDlpDDyUdh6orUSeV4+O2tj2TvTfq++NgDga
itqWqHxJDdc+CwZp2JHn
=mFb1
-----END PGP SIGNATURE-----