-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add a partial update User endpoint #108
Conversation
I had broken the user login part of rapidoc a while back. This fixes it
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.
@calebbourg Looks really great, I like the new UpdateMap pattern and IntoUpdateMap trait a lot.
One question I'm curious for your thoughts on inline.
) -> Result<users::Model, Error> { | ||
let existing_user = find_by_id(db, user_id).await?; | ||
let active_model = existing_user.into_active_model(); | ||
Ok(mutate::update::<users::ActiveModel, users::Column>( |
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.
Nice, we're consistent in our verbiage of mutate
in both the backend here and the frontend with my recent API refactoring work. And they hold very similar meanings. This is a very good thing.
pub github_profile_url: Option<String>, | ||
} | ||
|
||
impl IntoUpdateMap for UpdateUserParams { |
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 love this pattern for updating just the right fields - it's extremely clean, easy to understand and effective.
Description
This PR introduces a pattern for providing partial updates to database tables via our API.
By partial updates I mean that we are able to modify a subset of columns for any given table without having to provide values for the the other columns. The pattern is somewhat based on the pattern for filtering queries as introduced in #102
Note: This new endpoint assumes that the user being updated will always be the current user (as noted inline in comments). At some point we will likely want a user to be able to make updates to another user. We can decide how the code diverges at that point when we know more about how we want that to work.
Changes
update
functionPUT /users
update endpointTesting Strategy
I was able to test partially updating a user in Rapidoc
Coming Up