-
-
Notifications
You must be signed in to change notification settings - Fork 481
Implement simple query API #304
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
Conversation
@sfackler, no need to review yet, but your input on first two TODOs would be helpful at this point. |
You can assume strings are UTF8. You can also assume that the backend will send you the data it's documented to, but I'd return a bad_message error rather than panicking. |
The simple query API is a more robust version of `batch_execute`. Like that method, `simple_query` allows passing a `&str` of semicolon delimited queries. Divergence from `batch_execute` is in the return type; instead of nothing, a `Vec<TextRows>` is returned. Each entry in this `Vec` is the result set of one query in the query string. Thus if there are two semicolon delimited queries, there will be two entries in this `Vec`. The `TextRows` and `TextRow` types returned from `simple_query` closely mirror existing `Rows` and `Row` types with one major difference: only string values can be retrieved from them. There are a few TODOs in the code: * Are text values in this case guaranteed to be utf-8 encoded? * unwrap call in simple_query which assumes RowDescription is always sent * documentation (denoted with either STUB or TODO)
Should always be utf8 in practice, but there's no point in panicking.
Also fixes the return type to be consistent with regular "Rows" API.
Hey @sfackler, I finally got around to polishing this up, and it's ready to review! Thanks for letting this sit idle for so long in the PR queue. |
postgres/src/text_rows.rs
Outdated
self.columns | ||
} | ||
|
||
/// stub |
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.
Need to finish the docs here.
This seems pretty reasonable to me. Seems like we might want to deprecate/remove batch_execute since this basically replaces it, right? |
postgres/src/lib.rs
Outdated
result.push(TextRows::new(cols, mem::replace(&mut rows, Vec::new()))); | ||
} | ||
} | ||
_ => {} |
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.
Are there other messages we'd expect to get here? Ideally we'd be a bit more defensive and return an unexpected message error like we do elsewhere.
Both of the review items have been resolved. For |
Friendly ping in case this slipped past your radar |
Sorry for the delay! Yeah, let's deprecate batch_execute. While you're here, I'd be interested for your thoughts on #346 :) |
The deprecation was added in the most recent commit. |
Oops, I guess I should fix the tests as well! |
It's being replaced by the more capable `simple_query` API.
Fixed; tests are green now. |
Thanks! |
The simple query API is a more robust version of
batch_execute
. Likethat method,
simple_query
allows passing a&str
of semicolondelimited queries. Divergence from
batch_execute
is in the returntype; instead of nothing, a
Vec<TextRows>
is returned. Each entry inthis
Vec
is the result set of one query in the query string. Thus ifthere are two semicolon delimited queries, there will be two entries in
this
Vec
.The
TextRows
andTextRow
types returned fromsimple_query
closelymirror existing
Rows
andRow
types with one major difference: onlystring values can be retrieved from them.
There are a few TODOs in the code:
sent. Is this valid?
One other question that came up was whether
get
andget_opt
should handlenull
specially.TextRow::get_inner
currently returns anOption<Option<&str>>
, but perhaps anOption<&str>
can be used with an empty""
value when the field is null.This is the API discussed in #303. For reference, this is what was discussed/implemented: