-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
insert
is inconsistent, and should be changed to match other operations
#30
Comments
How would we feel about reversing the order? insert(record).into(table) It feels more consistent to me with action(record).action_specific(parameter) So we would be left with the API insert(record).into(table)
update(record).set(changes)
delete(record) |
Would it though? update(users.filter(id.eq(1))).set(user_changes)
delete(users.filter(id.eq(1))
insert_into(users).values(new_user) vs update(users.filter(id.eq(1))).set(user_changes)
delete(users.filter(id.eq(1))
insert(new_user).into(users) there's also the third option (not mutually exclusive) new_user.insert_into(users) |
I do want to end up supporting |
Through usage, it has become clear that in the overwhelming majority of cases, you either expect N records, or exactly 1. Expecting either 0 or 1 is uncommon. However, it's a completely valid use case, and having to match against `Err(NotFound)` is a pain, especially if you intend to use `try!`. Keeping that in mind, `QueryResult` now has the `optional` method, which converts `QueryResult<T>` to `QueryResult<Option<T>>`, treating `NotFound` as `None`. Since [`result::Error` is not exhaustively matchable](5435e30), I do not think we need to change the error type in this method. Since checking for and handling `NotFound` seems like a common case, particularly for returning a 404 response in a web server, it has been re-exported in the root namespace. I was going to open a PR to get feedback on this change first, but after making it, I feel the code quality improvement in our tests (especially the doctests, where we've removed most `.unwrap()` calls) was enough to convince me this is the right change.
This is just an artifact of the fact that I implemented this before everything other than the most basic forms of select. This should be changed to match
update
anddelete
. This is the API I'm imagining:This would return a command that can be used in the same way the return values of
update
anddelete
, which will be less painful with #29.Since this represents a breaking change in one of the most common APIs, we should do this sooner rather than later.
The text was updated successfully, but these errors were encountered: