3 ms·

The timestamp doesn't give you enough information to answer the questions it's typically going to be used for. It tells you "when", but not "who", and "what els

The timestamp doesn't give you enough information to answer the questions it's typically going to be used for. It tells you "when", but not "who", and "what else at the same time". A change history is a better solution, which would track: * transaction requestor (user/job/etc) * transaction timestamp * diff encoding before/after state Then if someone asks "why were these customer's disabled", we can answer "the XYZ cronjob went rabid and tore them down." and then hopefully use the diffs to reverse the transactions.

TheRealPomax 4y ago
Sure, but now you REALLY changed the game. If you're currently using a boolean, switch it to a timestamp. There are no real world downsides.
idealmedtech 4y ago
I recently converted some generation code to use a plan, so you can make a plan and then execute the plan. Architecting your code this way gives you things like dry runs and rollbacks for free; I feel like diff storage is in a similar realm of usefulness.
maxbond 4y ago
Timestamps are a huge observability win relative to the amount of effort they take. "When" will give you hints to pull the other information out of logs etc. What you're proposing is better, but is a heavier lift; if you have capacity for that, awesome, if you don't, timestamps go a long way, take very little time to implement, and not having any information will really sting.
bwilliams 4y ago
I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.
horsawlarway 4y ago
Sure - this is objectively better for tracking/auditing, but... now we're getting back into trade-off territory. Where is that change history stored? How much data are the diffs generating? Are we deriving the final state from the log, or can the log the and record disagree? Basically - this is now back in the "What is this history buying us?" realm, not in the "easy win" realm. In some cases it can be absolutely worth it. But probably not all.

TheRealPomax 4y ago

Sure, but now you REALLY changed the game. If you're currently using a boolean, switch it to a timestamp. There are no real world downsides.

idealmedtech 4y ago

I recently converted some generation code to use a plan, so you can make a plan and then execute the plan. Architecting your code this way gives you things like dry runs and rollbacks for free; I feel like diff storage is in a similar realm of usefulness.

maxbond 4y ago

Timestamps are a huge observability win relative to the amount of effort they take. "When" will give you hints to pull the other information out of logs etc. What you're proposing is better, but is a heavier lift; if you have capacity for that, awesome, if you don't, timestamps go a long way, take very little time to implement, and not having any information will really sting.

bwilliams 4y ago

I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.

horsawlarway 4y ago

Sure - this is objectively better for tracking/auditing, but... now we're getting back into trade-off territory. Where is that change history stored? How much data are the diffs generating? Are we deriving the final state from the log, or can the log the and record disagree? Basically - this is now back in the "What is this history buying us?" realm, not in the "easy win" realm. In some cases it can be absolutely worth it. But probably not all.