Skip to content
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

Discussion: get_many getters are impractical #7

Open
OtaK opened this issue Feb 16, 2021 · 1 comment
Open

Discussion: get_many getters are impractical #7

OtaK opened this issue Feb 16, 2021 · 1 comment

Comments

@OtaK
Copy link
Contributor

OtaK commented Feb 16, 2021

Hey!

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.

@NyxCode
Copy link
Owner

NyxCode commented Feb 16, 2021

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)]?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants