Skip to content
This repository was archived by the owner on Sep 25, 2025. It is now read-only.

Changes to RSVP model#53

Closed
conr wants to merge 2 commits into
freeCodeCamp:masterfrom
conr:rsvp-tweaks
Closed

Changes to RSVP model#53
conr wants to merge 2 commits into
freeCodeCamp:masterfrom
conr:rsvp-tweaks

Conversation

@conr
Copy link
Copy Markdown
Contributor

@conr conr commented Oct 16, 2019

  • Replace date with accepted_at/declined_at
    • I think we should keep things flexible allow for both declining and accepting. For instance someone could initially accept and subsequently decline later on.
  • Fix whitespace

I did not add not null constraints to accepted_at/declined_at as we could potentially allow for invites, meaning we could have RSVPs without either in a pending state.

Happy to hear people's thoughts on this one though.

- Add not null constraints to user_id and event_id
- Replace date with accepted_at/declined_at
- Fix whitespace
@viniciusalonso
Copy link
Copy Markdown

Good job! I only would like to discuss some case to you.

  • How to get ordered list of users in waiting list?

In this case we would have to filter by on_waitlist and order based on what field? Considering that we have now accepted_at and declined_at. For this reason I think that would be better keep the date field.

To keep the flexible that you have mentioned I think that would be more interesting replace accepted_at and declined_at for a boolean is_accepted.
Therefore, we keep that control over if user was accepted and also keep a simple way to get our waiting list.

Anyway, good job, I hope that my opinion was valuable. :)

Comment thread data/ddl.sql
@conr
Copy link
Copy Markdown
Contributor Author

conr commented Oct 16, 2019

Thanks for the feedback!

I guess it depends on what we're trying to achieve here.

Do we care about the history of these RSVPs? As in if a user accepts now and declines later and vice versa. Currently we'd miss out on this info on top of not knowing whether someone declined or not.

We're also constrained by the composite primary key of user_id and event_id such that we only know about the latest changes whereas we may care about those changes if we stay with the current model.

Perhaps we should store an enum response_status to capture this instead?

@viniciusalonso
Copy link
Copy Markdown

Maybe the idea of use an enum could be a good approach.

On my previous commentary I was thinking in get an ordered list of all users in waiting list. Because when someone that has accepted his invite to event decide does not go. Therefore, the first user on waiting list could be receive an invite.

In resume I care about keep a ordered list to invite users in waiting list on the correct sequence.

@kognise
Copy link
Copy Markdown
Member

kognise commented Oct 18, 2019

To be clear, do we intend to have waiting list functionality? For example, if a user tries to RSVP to an event that's full are we planning on adding them to a waiting list and contacting them if a spot is open as part of the MVP?

@vkWeb
Copy link
Copy Markdown
Member

vkWeb commented Oct 24, 2019

@conr I really appreciate your work on this but we are keeping things simple with MVP. This is something we'll consider for post MVP release.

I would encourage you to create an issue for this. I'll add it to the roadmap. :)

Closing this since it's not MVP specific.

@vkWeb vkWeb closed this Oct 24, 2019
@chrismgonzalez chrismgonzalez mentioned this pull request Oct 24, 2019
17 tasks
@allella
Copy link
Copy Markdown
Contributor

allella commented Oct 24, 2019

#53 has been linked to from #84 for future reference.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants