Lack of helpers like fetch_one/fetch_one_optional available for SelectBuilder

[dbxfb]

I found myself rewriting these helpers in an ad-hoc fashion, I was wondering if having these helpers only on QueryBuilder was an intentional choice or just an oversight?

[lex148]

Yes, this does appear to be an over site. I will get it Added

[dbxfb]

I haven’t looked too close, but I’d assume we could share the helpers using an additional trait?

[lex148]

good morning @dbxfb I have added these helpers to the select_col style queries. code is up on main

please note, the are currently under the "unstable-api" feature. You will need to enable this feature to use them for just a bit. I do this as a way to mark parts of welds as "subject to change" kinda like the nightly branch of rust. code is stable, but might tweak the way they are called just slightly.

I would expect them to be just normal calls by the next release of welds.

[dbxfb]

@lex148 I cannot re-open this issue: for some reason QueryBuilder::fetch_one builds a DbState<T> but SelectBuilder::fetch_one builds a T.

Is the difference in API intentional? (that’s one of the reasons I had suggested sharing the code in my comment)

[lex148]

So yes, it was intentional but am open to discussion. When using the SelectBuilder side of welds you are most likely not selecting the contents of the table directly otherwise why not just load the model. The main use case here is selecting rows of two tables joined together or possibly using aggregate functions like count and sum. For both these scenarios it would be very confusing to have a DbState since you wouldn't be able to save/update.

[dbxfb]

My use case here is the one I described in #150: I have objects that use integer primary keys that refer to each others, but the final view presented beyond the system querying the database actually presents UUID. I do this by loading the UUIDs through join queries into fields that are #[welds(readonly)] as previously discussed. The autoincrement primary keys aren’t exposed externally (essentially #[serde(skip)] on that field for now).

This is compatible with DbState since I read all columns from the main table, and the joined fields are marked readonly. I make it work by using DbState::db_loaded.

The reason I commented here is because I was surprised that calling fetch_one failed, with trait errors around DbState. Admittedly, I had not checked the signature, and when I did I realized it wasn’t the same as the equivalent on QueryBuilder. I think your point of view is reasonable, DbState is probably not the most frequent use case for SelectBuilder.

I’m curious: is there a way DbState could be extended so that fetch_one can build one assuming the contained type can be populated? In that case both implementations could return either T or DbState<T> and the user can select through type annotation.

(do you think this would be too confusing or complex?)

[lex148]

It's an interesting Idea. I think I will explored and see if it is possible