-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(db)!: Add a last-modified timestamp to each session. #731
Conversation
06d7f53
to
3432c80
Compare
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. |
-- We can revisit this if the performance impact of 'getCurrentTime' | ||
-- becomes a problem. | ||
now <- liftIO getCurrentTime |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any references/data on the performance of getCurrentTime
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good. I have some minor comments/requests above though.
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
3432c80
to
9debe0a
Compare
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. |
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