MockDatabase getting wrong results

[DMaxter]

Description

When using a MockDatabase to retrieve a value that we want to not exist, it gives us the wrong value. For example, if I have in it a Product with id 1 and ask for Product with id 2, it gives me the Product with id 1 instead of not returning a product at all

Steps to Reproduce

Let's take for example, https://github.com/SeaQL/sea-orm/tree/75f7d4fa57aaeaeee88ca43dda99ed602cdcc930/examples/axum_example :

If we have this test which adds a Post with id 1 and we ask for id 2:

diff --git a/examples/axum_example/service/src/query.rs b/examples/axum_example/service/src/query.rs
index e8d2668..a302cea 100644
--- a/examples/axum_example/service/src/query.rs
+++ b/examples/axum_example/service/src/query.rs
@@ -24,3 +24,22 @@ impl Query {
         paginator.fetch_page(page - 1).await.map(|p| (p, num_pages))
     }
 }
+
+#[cfg(test)]
+#[tokio::test]
+async fn test() {
+    use sea_orm::MockDatabase;
+
+    let db = MockDatabase::new(sea_orm::DatabaseBackend::MySql)
+        .append_query_results([vec![post::Model {
+            id: 1,
+            title: String::from("abc"),
+            text: String::from("bla"),
+        }]])
+        .into_connection();
+
+    let post = Query::find_post_by_id(&db, 2).await;
+    println!("{:?}", post);
+
+    assert!(post.unwrap().is_none());
+}

and try to run it with cargo test -p axum-example-service --features axum-example-service/mock we will get an error

Expected Behavior

Test runs with no issue

Actual Behavior

running 1 test
test query::test ... FAILED

failures:

---- query::test stdout ----
Ok(Some(Model { id: 1, title: "abc", text: "bla" }))

thread 'query::test' panicked at service/src/query.rs:44:5:
assertion failed: post.unwrap().is_none()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    query::test

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p axum-example-service --lib`

As we can see, it returns Post with id 1, even though we asked for Post with id 2

Reproduces How Often

Always

Workarounds

None as not testing for this case is not really a workaround but rather making a test suite incomplete

Reproducible Example

Example provided above as it is very simple

Versions

sea-orm-axum-example v0.1.0 (/tmp/sea-orm/examples/axum_example)
└── axum-example-api v0.1.0 (/tmp/sea-orm/examples/axum_example/api)
    ├── axum-example-service v0.1.0 (/tmp/sea-orm/examples/axum_example/service)
    │   ├── entity v0.1.0 (/tmp/sea-orm/examples/axum_example/entity)
    │   │   ├── sea-orm v1.1.5 (/tmp/sea-orm)
    │   │   │   ├── sea-orm-macros v1.1.5 (proc-macro) (/tmp/sea-orm/sea-orm-macros)
    │   │   │   │   ├── sea-bae v0.2.1 (proc-macro)
    │   │   │   ├── sea-query v0.32.2
    │   │   │   │   ├── sea-query-derive v0.4.2 (proc-macro)
    │   │   │   ├── sea-query-binder v0.7.0
    │   │   │   │   ├── sea-query v0.32.2 (*)
    │   └── sea-orm v1.1.5 (/tmp/sea-orm) (*)
    ├── entity v0.1.0 (/tmp/sea-orm/examples/axum_example/entity) (*)
    ├── migration v0.1.0 (/tmp/sea-orm/examples/axum_example/migration)
    │   └── sea-orm-migration v1.1.5 (/tmp/sea-orm/sea-orm-migration)
    │       ├── sea-orm v1.1.5 (/tmp/sea-orm) (*)
    │       ├── sea-orm-cli v1.1.5 (/tmp/sea-orm/sea-orm-cli)
    │       │   ├── sea-schema v0.16.1
    │       │   │   ├── sea-query v0.32.2 (*)
    │       │   │   └── sea-schema-derive v0.3.0 (proc-macro)
    │       ├── sea-schema v0.16.1 (*)

[DMaxter]

Okay, after a lot of looking into the issue, it seems that we need to define what each query will return.
This doesn't seem like a good approach...

Wouldn't it be better if it mocked better a database by allowing us to add objects there and return them with the needed conditions? A bit like what we can do with Hibernate/JPA.

Because, from my perspective, it seems that the queries need to be performed in a certain sequence, which kind of goes against having multiple queries being performed in an asynchronous matter. It would only be possible to fulfill this use case by using a different mock for each query that is performed concurrently, thus guaranteeing that the tests don't fail, even if the queries run in different orders (which might happen).