feat(db)!: Add a last-modified timestamp to each session.

[dhess]

Note that "modified" here means any edit, including session name changes. Read-only session queries don't update the timestamp.

BREAKING CHANGE: this change requires a database migration. If you want to preserve your existing local PostgreSQL database, you must run the deploy-local-db script against it. Assuming your PostgreSQL Docker container is running, run this:

nix run .#deploy-local-db

Closes #247
Closes https://linear.app/hackworthltd/issue/PRIM-20

[linear]

PRIM-20 Add a timestamp to sessions

#247

[dhess]

Sorry for the one massive commit. With database schema changes, there's no good way to stage the changes in multiple commits without breaking the build along the way.

[brprice]

Do you have any references/data on the performance of getCurrentTime?

[dhess]

I haven't looked into the details of how it's implemented in time, but I believe the general consensus is that reading the system's real-time clock is a relatively expensive operation. We would need to measure it for our specific case (our app, running on Fly.io, with a realistic load) to know for certain, hence the hedge.

I don't claim that this is representative of our case, but here is an example of how it can be problematic on EC2 instances:

https://careers.appian.com/blog/the-tech-corner/yet-another-reason-your-docker-containers-may-be-slow-on-ec2-clock_gettime-gettimeofday-and-seccomp/

[brprice]

Sorry for the one massive commit. With database schema changes, there's no good way to stage the changes in multiple commits without breaking the build along the way.

One thing that you could do is to split the code changes in two. One "plumbing" commit adding dummy arguments to constructors and functions, and one "useful" (much smaller) one that does the schema change and actually gets the current time etc. I'm not convinced how much easier to understand that would be though.

(In any case, I don't think it is worth changing this PR now)

[brprice]

Generally looks good. I have some minor comments/requests above though.

[dhess]

Sorry for the one massive commit. With database schema changes, there's no good way to stage the changes in multiple commits without breaking the build along the way.

One thing that you could do is to split the code changes in two. One "plumbing" commit adding dummy arguments to constructors and functions, and one "useful" (much smaller) one that does the schema change and actually gets the current time etc. I'm not convinced how much easier to understand that would be though.

(In any case, I don't think it is worth changing this PR now)

I considered that, but figured that the work needed to shunt out the dummy values at the PostgreSQL interface would be extra work that in the very next commit would need to be ripped out, so decided against it.