Skip to content

Rework RideType for new standardized schema #598

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.

Sign up for GitHub

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

Open
benkoppe wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Rework RideType for new standardized schema #598

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8d01ff1
Create start guide for new rides model on backend side
benkoppe Oct 6, 2025
a8fe9ec
Write second step of implementation guide with TODO tasks in router/r…
benkoppe Oct 6, 2025
883bd87
Write TODO task for third step in frontend after backend code is migr…
benkoppe Oct 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions server/src/models/ride.ts
View file
Open in desktop

@mjaydenkim mjaydenkim Oct 6, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very small note b/c this schema looks great to me, but I feel like creating a RideType2 on top of the existing RideType will be confusing -- maybe we should name it RideTypeWithRecurrence or something b/c it might be poor documentation-wise to just name it RideType2

@benkoppe benkoppe Oct 6, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's definitely only meant to be a temporary switch from RideType. I thought it might make sense to have a separate type that avoids deleting/modifying the original, so we don't break the entire codebase at once, and then at the end we can delete the original RideType and rename RideType2. But this might be difficult for the external dynamoDB, so I'm not sure.

Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,23 @@ export enum Status {

// Use the proper LocationType instead of custom RideLocation

/* TODO: Create new type `RideType2` that contains
- id
- riders
- driver?
- requestedPickupTime
- finalPickupTime?
- requestedDropoffTime

@anika-4444 anika-4444 Oct 7, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the user does not know exactly how long their ride will take, I'm not sure requested drop off time is a necessary field. Currently, the modal for student and admin ride creation should not allow for the user to pick their drop off time according to the bug bash notes. However, I still think storing a general end time is a good idea, especially for the day calendar that displays rides. I'm currently working on using Google Maps data to add a ride duration estimate (with added buffer minutes) for the student and admin ride view. That data might be better here than requested drop off time.

- finalDropoffTime?
- requestedPickupLocation
- finalPickupLocation?
- requestedDropoffLocation
- finalDropoffLocation?
- schedulingState: create type
- operationalStatus: create type
- recurrenceId?
- breaksRecurrence?
*/
export type RideType = {
id: string;
type: Type;
Expand Down