Provide get_optional

[heroin-moose]

Since there is no easy way to check why sqlx query failed it would be nice to have something similar to https://docs.rs/sqlx/0.5.10/sqlx/trait.Executor.html#tymethod.fetch_optional

[kurtbuilds]

This is straight-forward - I can add this later today.

[kurtbuilds]

I looked into this. What struct are you wanting fetch_optional on? I checked, and SelectQueryBuilder.fetch_optional does already exist.

I (believe I) just fixed the docs issue, though it seems like it takes time for changes to propagate from crate to docs.rs. Once it does though, hopefully the API will be more discoverable.

[heroin-moose]

Do I understand correctly that SelectQueryBuilder is e.g. select()?

Then

Example::select().filter("name = ?").bind(&name).fetch_optional(pool).await?

vs

Example::get_optional(&name, pool).await?

IMHO the second one is far easier to grasp.

[kurtbuilds]

Yeah, that first query is how to do it with the current API.

To confirm, the current get_one API takes an pkey field, which is typically id, not name. Are you asking for a get_optional on the pkey field?

It could make sense to add this API. I'm confused how common this use case is though. What's the scenario where you want to get an id, but you're not sure if it exists yet? (How would you even have the ID value?)

[heroin-moose]

To confirm, the current get_one API takes an pkey field, which is typically id, not name. Are you asking for a get_optional on the pkey field?

Yep.

It could make sense to add this API. I'm confused how common this use case is though. What's the scenario where you want to get an id, but you're not sure if it exists yet? (How would you even have the ID value?)

Sometimes ID is not an ID but a slug or a name.

[kurtbuilds]

Why would the pkey field be the slug or name? That seems quite brittle, e.g. if you need to change an article's title.

[heroin-moose]

However if you have a list of servers that must have unique names this simplifies the API.

[kurtbuilds]

You're presenting multiple examples, which makes me think you're talking about hypothetical requirements, rather than trying to solve a problem you're actively encountering as you build a service. We strive to build the API based on real-world usage. Unless you're in that situation, I'm going to push off further discussion on an API like you're suggesting here.

[heroin-moose]

Nah, I'm asking because that's what I'm missing writing a server. It's not a web service and one of the main route to use it is via CLI. So basically when user types foobarctl do this <name> it's easier to ask the API by name instead of by id because CLI tool won't cache them.

[heroin-moose]

However, you may be right that there are better ways to do what I want. I'm going to close it.