-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[Postgres] RowNotFound when mapping enum to varchar column #237
Comments
Forgive me but, I'm a bit confused. Your SQL as written in the issue will never return rows in postgres. You would need a Can you double check that you copied over the right query? |
Argh you're right! My bad. The real queries do indeed have |
It turns out that when resolving the type name in postgres, the executor uses PR incoming to make this more flexible! |
Thank you @qtbeee for investigating and pushing a fix. |
Thanks for the fix! It works for my code as well. It would be very useful if the list of types was either documented, or better, validated in the macro. |
@jamwaffles Can you help me understand what you mean with:
We have basic type documentation here: https://docs.rs/sqlx/0.3.3/sqlx/types/index.html and https://docs.rs/sqlx/0.3.3/sqlx/postgres/types/index.html I think the primary issue here ( aside from the obvious mistake in the implementation ), is the error message you received.
That's awful as it has nothing to do with what actually happened. The sqlx/sqlx-core/src/postgres/executor.rs Lines 263 to 270 in cd6735b
This should definitely be tweaked to be a
That would have made the bug in the implementation much more obvious. |
Added an issue to track improving that error message |
In the proc macro code, it could hold a list of known valid values for the
I didn't know those pages existed to be honest. The docs for the
Yeah, agreed! We followed quite a few false starts tracking the root cause down :) |
I believe the normal idea is you're supposed to just use the type of the SQL column. Note that the original intention of the feature is more to allow this: CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy'); #[derive(sqlx::Type)]
#[sqlx(rename = "mood", rename_all = "lowercase")]
enum Mood { Sad, Ok, Happy } So there really isn't a list of "known valid values". Supporting simple string matching
Yeah.. that's definitely on us. We're trying to build up the documentation as we go but it's definitely not in an amazing place right now. That's a good point on linking to the types module from the All in all, I'm glad the fix is working for you and sorry for the troubles. We'll get a patch release out shortly. |
Thank you for explaining the intent of this feature. It makes a lot more sense when used in the context of custom types for sure. As a fellow open source maintainer I appreciate that docs are time consuming and sometimes annoying lol. It looks like this crate is also moving pretty quickly so keeping docs up to date would be even more of a burden I imagine.
No apology required, and thank you for your time working through this with me! |
I'm trying to read/write enums to/from a
varchar not null
column in Postgres. This issue may also exhibit in other databases, but I haven't tested them. As far as I can see from the docs, creating an enum like the following should allow me to use it in a query:My insert statement looks like this:
The record is never created in the database, and the insert panics with this message:
Removing the
UserType
enum from the insert lets it work as normal, and inserts the record into the database.I've tried changing
#[sqlx(rename = "TEXT")]
to#[sqlx(rename = "varchar not null")]
to mirror the column type to no avail (see case below).Is this a bug, or am I not following the docs properly? I found some stuff in
CHANGELOG.md
about this but it's not very clear.This is the reduced (as much as possible) test case.
Note that removing all
serde
stuff doesn't fix the issue, so it's not serde messing with things.Cc @Istar-Eldritch who's been helping me fight this issue.
The text was updated successfully, but these errors were encountered: