Consolidate date query schema across endpoints #74
Comments
|
The choices currently available are |
5 tasks
andrew-wang0
added a commit
that referenced
this issue
Jan 15, 2025
## Description
Adds study room slots and availability to study room endpoint.
As previously implemented in the data pipeline, availability is
available in on the days between the day of the current time in UCI's
timezone (`America/Los_Angeles`) and exactly 3 days later, inclusive.
Data is updated every 2 minutes.
This PR simply exposes that data. We use ISO 8601 dates ~~(most
precisely, `z.string().datetime({ local: true })`) which are given with
the `Z` indicating UTC but should be interpreted as being in UCI's
timezone~~. We ask Postgres to interpret the `TIMESTAMP NO TIMEZONE` in
`America/Los_Angeles` and format as zoned ISO 8601, avoiding adding a JS
timezone library.
**Note**: The `slots` field on returned study rooms is now guaranteed to
exist. This is not a breaking change.
We use a materialized view to precompute the JSON structure of the
response. The refreshing of this view is relatively light and is done as
part of the study room and slot scraping process every 2 minutes.
However, it is not completely trivial; see below demonstrating that it
produces a significant speed improvement per request which will accrue
over time. **This design decision is a database schema change.** Since
we have this JSON structure beforehand, we need only `SELECT` with
conditions when serving a response.
## Related Issue
Feature update as requested in #46. ~~Also closes the inconsistency
raised in #74 since study room data was one of the offenders and is
within the jurisdiction of this PR.~~ It doesn't.
## Motivation and Context
>be me
>want study room slots
>no study room slots
mfw
## How Has This Been Tested?
Tested with Postman on a local deployment.
## Screenshots (if appropriate):
### Old screenshots (before timezone correction):
REST is functional:
GraphQL is functional:
### New screenshots (latest):
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
## Checklist:
- [x] My code involves a change to the database schema.
- [ ] My code requires a change to the documentation.
---------
Co-authored-by: Andrew Wang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow up to #73
Possible Solution
See #73, but apply this to the
dateparamThe text was updated successfully, but these errors were encountered: