[dev] History of share changes

Chuck Hagenbuch chuck at horde.org
Fri Aug 14 00:16:22 UTC 2009


Quoting Jan Schneider <jan at horde.org>:

>>>>> I don't see any problem with the history system per se. I doubt  
>>>>> that having the date attributes with the original data will have  
>>>>> much if any performance improvement over a separate table.
>>>>> Having a central place for all history data is much better  
>>>>> maintenance-wise too, we would not only need a place to track  
>>>>> deleted data, but we also have history that's not related to  
>>>>> anything stored in our database, like message history.
>>>>
>>>> That's true, and all good reasons, and I made the darn History  
>>>> API in the first place so I should be partial to it. However I'd  
>>>> also had trouble when trying to deal *just* with an app's data,  
>>>> and needing to pull in history also. What do you think of storing  
>>>> them in both places? Horribly non-normalized I know.
>>>
>>> For simple information that's really required together with the  
>>> entities, like the modification date, this might be doable. But  
>>> for anything more complex like what's done in History now (who did  
>>> what and when), I'd vote against duplication.
>>
>> Agreed. I've been thinking just create and modify datetimes.
>
> Out of curiosity: what would we need this for? For displaying in the  
> UI this is not sufficient, as long as we still want to display the  
> last editor like we do now. Which is a good idea.

True. I honestly forget what I was looking at that made it useful.  
Maybe the browse() methods; I'm not certain.

-chuck


More information about the dev mailing list