-
Notifications
You must be signed in to change notification settings - Fork 336
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make
query_row
a synonym for query_row_safe
.
This is a breaking change for anyone using `query_row`. To update code that used the old `query_row`, you must now `.unwrap()` the returned result.
- Loading branch information
Showing
3 changed files
with
27 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
03be8e0
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.
Cool! I was just thinking,
query_row_safe
was never really 'safe', as you could just pass the identity function and get the underlyingSqliteRow
object. To make it really safe, we should add aT: 'static
bound. What do you think?03be8e0
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 think that would be too restrictive, wouldn't it? You wouldn't be able to capture any references in
f
at all, which would otherwise be fine.03be8e0
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.
You are correct, I was thinking about the more general case. The point is that I don't see why you would ever want to capture a reference to the
SqliteRow
object anyway.The idea I'm playing with is having
SqliteStatement
not return an iterator overSqliteRow
s, but an iterator overT: 'static
(after passing it a map as inquery_row_safe
). Would that not make the interface panic free, whilst maintaining the full ergonomics ofIterator
, includingcollect
!Am I missing something?
Edit: so this would change the
query
method's signature onSqliteStatement
toEdit2: deadly typo: how -> why
03be8e0
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.
Interesting. So something like this?
where
MappedRows<T>
is an iterator? That would be pretty great.03be8e0
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.
Hah, we were close. I think
F
has to beFn
(so you can call it for each row). Oh duh, you're right that it can just takeSqliteRow
(not a ref) sinceSqliteRow
is already non-'static
.I'm less sure about replacing query outright. It seems like there might be some uses that are currently possible that this wouldn't cover, but I can't think of any off hand...