You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to work with the get_many getters lately and they're essentially useless IMO because:
They take a single argument and perform a = test on it in the SQL query
They will return a single row in cases you're searching something like a UNIQUE index.
Meaning that you will have to resort to manual SQL queries if you're doing something as trivial as looking multiple records by a batched id/unique key.
I suggest changing the query in get_many to use a IN() statement instead of = and accepting a slice of arguments instead of a single one as it would semantically work as well.
But of course, as it'd be a breaking change, I'm triggering a discussion here.
I can take care of the implementation.
The text was updated successfully, but these errors were encountered:
I agree, get_many is pretty limited right now. It was intended for something simple like User::get_by_role(Role).
As far as I can remember, sqlx is still picky when it comes to encoding arrays of user-defined types to postgres. Therefor, I'd suggest we just create a new attribute for this, maybe #[ormx(get_any)]?
Hey!
I've been trying to work with the
get_many
getters lately and they're essentially useless IMO because:=
test on it in the SQL queryMeaning that you will have to resort to manual SQL queries if you're doing something as trivial as looking multiple records by a batched id/unique key.
I suggest changing the query in get_many to use a
IN()
statement instead of=
and accepting a slice of arguments instead of a single one as it would semantically work as well.But of course, as it'd be a breaking change, I'm triggering a discussion here.
I can take care of the implementation.
The text was updated successfully, but these errors were encountered: