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

get all entities? #35

Open
open-schnick opened this issue Oct 26, 2024 · 6 comments
Open

get all entities? #35

open-schnick opened this issue Oct 26, 2024 · 6 comments

Comments

@open-schnick
Copy link
Contributor

Hi i have the following code expecting that i get one entity back which is not the case:

    let new_artist = Artist::create()
        .name("Artist")
        .exec(&db)
        .await
        .unwrap();
    
    Song::create()
        .title("Crazy Good Song")
        .artist(&new_artist)
        .exec(&db)
        .await
        .unwrap();

    let all_songs = Song::find_many_by_id()
        .all(&db)
        .await
        .unwrap()
        .collect::<Vec<Song>>()
        .await
        .unwrap();

    assert_eq!(all_songs.len(), 1);

Is this a api misuse by me or a bug in the application?
Also i think having a Song::find_all() would make sense from a readability and usability perspective

PS: I know logging is on the roadmap but here having tracing log the executed statement would make it easier to debug

@open-schnick
Copy link
Contributor Author

open-schnick commented Oct 26, 2024

i am also happy to help implementing tracing but i am not really an expert on the correct usage of tracing in libs especially when performance is a concern

@dmgolembiowski
Copy link

hey hayden @hds
you're lowkey a subject matter specialist on this. any suggestions?

@carllerche
Copy link
Member

Adding tracing support would be welcome. We can do it incrementally.

@carllerche
Copy link
Member

Hi i have the following code expecting that i get one entity back which is not the case:

    let new_artist = Artist::create()
        .name("Artist")
        .exec(&db)
        .await
        .unwrap();
    
    Song::create()
        .title("Crazy Good Song")
        .artist(&new_artist)
        .exec(&db)
        .await
        .unwrap();

    let all_songs = Song::find_many_by_id()
        .all(&db)
        .await
        .unwrap()
        .collect::<Vec<Song>>()
        .await
        .unwrap();

    assert_eq!(all_songs.len(), 1);

Is this a api misuse by me or a bug in the application? Also i think having a Song::find_all() would make sense from a readability and usability perspective

PS: I know logging is on the roadmap but here having tracing log the executed statement would make it easier to debug

This is not returning anything because this is the API to find many using a batch of IDs. You did not include any IDs so nothing is returned. I am on mobile so I will have to look into how to get all entities later. I know this isn’t supported on all data stores (eg dynamodb) so it will have to be an opt-in api based on target database support.

@kevinbader
Copy link

So find_many_by_id without IDs should not compile, right?

@carllerche
Copy link
Member

So find_many_by_id without IDs should not compile, right?

It would be nice if it didn't, but I don't know if there is an obvious way to achieve that without complicating the API. Toasty aims for a more straightforward public API at the expense of maximizing type state.

Another approach for find_many_by_id would be to take the ID batch as an argument. So something like:

Song::find_many_by_ids(&[id1, id2, id3])

It would probably have to be a T: IntoIterator argument to avoid always having to pass in a slice.

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

4 participants