[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