[horde] Shortening Histories

[Jan Schneider]

Zitat von Ralf Lang <lang at b1-systems.de>:

> On 09.01.2017 23:49, Michael J Rubinsky wrote:
>>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Ralf Lang <lang at b1-systems.de>:
>>>
>>>> Over the years, the Horde_Histories table can become quite large. It
>>>> may make sense to sort out entries we won't need anymore
>>>>
>>>> * Entries for users or items which have disappeared, been deleted
>>>> outside of horde or directly on the backend
>>
>> On the contrary, I would argue we should technically do the opposite and
>> create History entries for items that have been deleted outside of Horde
>> or directly on the backend so that Horde can be made aware of it. In
>> fact, this has come up recently on the ML, or maybe it was in an
>> enhancement request. Of course doing so is no easy task.
>
> I think I understand the intention behind this. Shareable and  
> syncable resources deleted by outside should also create the  
> necessary information to do the necessary to any client connector.
>
>>
>>>> * Changes so far past that we don't care anymore
>>
>> I wouldn't object to some configuration that would allow the table to be
>> trimmed after some configurable time (probably measured in years) but
>> there would need to be a pretty loud warning on the configuration page
>> that this could lead to changes being missed by sync clients.
>
> It was only something I wanted to apply to a specific installation.
>
> It should not be a default horde behaviour. Still, there should be  
> some way to make sure rarely-read histories don't slow down access  
> to histories which are more interesting. I am not sure at the moment:
>
> * Delegate this task to the DB administrator to solve this in  
> db-specific ways, i.e. table partitions by date field value so  
> indexes and searches won't be affected in most cases.
>
> * Provide some optional lru caching for Histories -> Horde_Cache,  
> Horde_Hashtable
>
> * Allow filtering changes that would not affect the most recent  
> state (an object that has been created and deleted years before now)  
> -> still destroys undo/undelete for very old items and sync for  
> clients with a very old last sync.
>
>>
>>
>>>> Will anything break if I delete far-past histories? I'd use code, not
>>>> bare DB statements.
>>
>> As Jan mentioned, sync clients would not receive any changes if they
>> have not yet synced the changes you delete. Additionally, IMP uses
>> History to write the Maillog - which stores things like if/when a
>> message was responded to etc... So if a message still exists and you
>> remove those entries you loose this trail.

I'd rather see the History backend to scale better. This way it  
wouldn't matter how much data you have there. We have actually some  
sponsoring for this, so this is going to happen some time.

-- 
Jan Schneider
The Horde Project
https://www.horde.org/