Initial Thoughts

[open-schnick]

Hi there,
thanks for your ongoing work and this crate. I think it does fill some kind of gap in the ecosystem.
That said i have some initial thoughts when playing around with the lib

1. When trying to access some referenced struct like the todos in the hello-toasty-example one always has to call todos.all(&db).await... before the first todos.get() otherwise one gets a panic. This is something i think could be represented with the typesystem via a generic.

2. For me when writing any high-level-application like a rest-service a orm has to one thing: Make it easy to fetch update and insert my data. This can be done right now with toasty and things like sea-orm aswell. But the real struggles appears when one tries to separate the database from the business-logic e.g by using DDD and a strong domain layer. Because then the persistence layer does not know anything about possible changes in the data anymore. It has to provide generic functions. Think about the following code:

let domain_user: domain::User = domain::User::new();
// here some business-logic happens. I dont actually know what (maybe the password changed?, maybe the username?)
// ...
// now i want to persist the changes:
let entity: db:User = domain_user.to_entity();
// in spring one can easily call repository.save(entity)
// here one has to know what changed to be able to save it which kinda defeats the purpose of a orm for me as this could be done with "simple" sql aswell

The reason i dont like any existing solutions currently is the fact that one cant really use a strong domain layer without leaking database stuff or heavy unmaintainable code chunks. I was hoping toasty could provide a way to do this.

4. I think it would be easier to use in-memory sqlite instead of dynamodb in the tests as this does not require any additional setup

5. For the same reason i cant really run the tests locally so one could maybe think about using testcontainer

[carllerche]

Thanks for taking the time to provide feedback. it is super helpful

1. When trying to access some referenced struct like the todos in the hello-toasty-example one always has to call todos.all(&db).await... before the first todos.get() otherwise one gets a panic. This is something i think could be represented with the typesystem via a generic.

I think that I know what you are talking about, but am not 100% sure. Could you include the code snippet so that I can make sure that I am on the same page?

Because then the persistence layer does not know anything about possible changes in the data anymore. It has to provide generic functions.

I thought to handle this case w/ the update builder:

    user.update()
        .password(new_password)
        .exec(&db)
        .await
        .unwrap();

Fundamentally, in order to persist an update, toasty needs to know what changed. I don't think that having the model itself track its own change set is a great idea. Instead, the approach is to have a separate type (here, the update builder) do the tracking. The update builder could be extended to provide more "getter" methods that let you read the in-progress updated values. Does something like this work for you?

The reason i dont like any existing solutions currently is the fact that one cant really use a strong domain layer without leaking database stuff or heavy unmaintainable code chunks. I was hoping toasty could provide a way to do this.

It would be great if you could share some examples of where the leaking or "unmaintainable code chunks" happened and what they look like.

4. I think it would be easier to use in-memory sqlite instead of dynamodb in the tests as this does not require any additional setup
5. For the same reason i cant really run the tests locally so one could maybe think about using testcontainer

All the tests already use sqlite in memory. How about we extend the test crate to add feature flags per datastore. Then you can pick the data store you want to test against locally and CI can handle the others?

[carllerche]

096c64d landed, so local tests default to only using sqlite in-memory

[open-schnick]

Concerning my 1. here is a code snippet somewhat taken from the example

let user = User::find_by_id(&u1.id).get(&db).await.unwrap();
// Here the todos are not loaded (which is good imo because this gives the user the flexibility to load them only when needed
// The user currently has no way to know whether or not which relation is loaded tho
// The naive way to get the todos would be:
let todos = user.todos(); // note due to type-system you have to assign them to a temp var which is imo not too nice
// and then call this
todos.get(); // which panics because you have to do the following
let real_todos = todos.all(&db).await.unwrap();

Maybe i dont understand what the .get() function tries to achieve

[open-schnick]

My 2. point is somewhat complex to explain but in enterprise the way to you would often develop complex high-level applications is by using a architectural-approach that completely separates the database entities from the domain types. Meaning that the user maps from and to the generated entities and therefore loosing the connection to things like the update builder.

When one does this the database mapping and interactions could be either:

1. Specific and expose functionality like update_user_name(user) (knowing that only the user_name will be updated). This requires that the use-cases "leak" into the database code. So the persistence layer needs to know which functionality is needed which defeats the purpose of the seperation. This could be generally achieved with basic sql(x)
2. Generic over all possible mutations of the entities. In Java there are libs like Hibernate that do this by heavily relying on runtime magic and exposing and api like repository.save(entity). Hibernate internally runs a SELECT decides whether this needs to be an UPDATE or INSERT statement, looking for all changes to the entity and then building a statement accordingly.

To be clear i am not sure if the second approach is really something one should wish for because it means a lot of Magic and performance implications.

What is the way that you expect the users to develop using toasty?
If i understand you correctly users

• use the generated types as domain types, spreading them throughout the codebase
• extend the functionality with additional impl blocks
• track modifications using the update builder
• sync the changes in the end by just calling exec on the update builder

[open-schnick]

The generic part could also be implemented by hand but this is what i mean by

heavy unmaintainable code chunks

Something like this (ignoring some move semantics)

async fn update_user(user: &DomainUser, db: &Db) {
    let mut entity = User::find_by_id(&user.id)
        .first(db)
        .await
        .unwrap()
        .unwrap();
    // all fields of the entity (this changes with schema changes and one has to think about that
    let persisted_name = entity.name.clone();
   
    let updater = entity.update();

    if persisted_name != user.name {
        updater.name(user.name.clone());
    }
   
    updater.exec(db).await.unwrap();
}