It seems that Ecto.Schema.timestamps() is used many times in the Ecto examples found in the net. I imagine that in some cases they are justified by functional requirements, like accountability, but since I find them too often, and without evident use, I believe I may be missing other relevant uses.
In particular, I would like to know if they are used to significantly contribute to some non-functional system quality, like reliability, security, and maintainability, among others. Do you know any of these non-functional uses for Ecto.Schema.timestamps/1 ?
Most commonly they act as a debugging tool for me. I might expect some operation to update a record, but see by the updated_at that it didn’t. Or, I might know a record has an incorrect state and can use the updated_at to see when it happened and try to figure out what else happened in the system around that time.
Most of the time when I omitted them, sooner or later, I regretted it - usually exactly during debugging some production issue. It’s generally useful to know when some data appeared in the system - an exact audit log would probably be even more useful, but inserted_at and updated_at is often a good first approximation.
Does anyone know about other non-functional requirements or software qualities for which Ecto.Schema.timestamps/1 might be useful, besides debugging and testability ?
inserted_at/created_at has obvious use cases, eg. when was this comment made, your primary key might not be sortable etc. etc.
updated_at perhaps less so except for vague audit and dev/debugging - one big one is caching and cache busting though - where you will use updated_at as part of the cache key - and do russian doll caching or similar (if you are coming out of rails you will most likely be quite the caching expert).
Ok, that is another non-functional requirement. In fact, reading Caching with Rails: An Overview helps to understand a lot this use for the Ecto.Schema.timestamps/1 macro. Perhaps it’s introduction in Ecto comes from this Ruby influence?
I need to keep everything in my database, so I actually replaced all my timestamps calls with timestamps_with_removed_at calls that adds a removed_at as well. These tables have primary keys disabled and instead of a unique index over the original primary key(s) and removed_at (with special allowances to handle it being null properly, I.E. two unique indexes, one for when it is not null and one for when it is, for note, this is roughly what a primary key is in PostgreSQL anyway, just a unique index with a not-null constraint on the index and field both). And on ‘most’ queries I just test that removed_at is nil to make sure I’m getting the active record. It’s a pattern I have to follow because of old database interactions so I just copied it’s method. I wish this method was baked into Ecto, but eh… It’s probably situation specific even though I’ve seen it used (and not started by me) at multiple jobs in my life.
