s/batching/chunking

query-engine/connector-test-kit-rs/query-engine-tests/tests/new/regressions/prisma_7434.rs

@@ -6,8 +6,6 @@ mod not_in_batching {
 
     #[connector_test(exclude(CockroachDb))]
     async fn not_in_batch_filter(runner: Runner) -> TestResult<()> {
-        runner.query(r#"mutation { createManyTestModel(data: [{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}]) { count }}"#).await?.assert_success();
-
         assert_error!(
             runner,
             with_id_excess!(
@@ -27,8 +25,6 @@ mod not_in_batching_cockroachdb {
 
     #[connector_test]
     async fn not_in_batch_filter(runner: Runner) -> TestResult<()> {
-        runner.query(r#"mutation { createManyTestModel(data: [{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}]) { count }}"#).await?.assert_success();
-
         assert_error!(
             runner,
             with_id_excess!(

query-engine/connector-test-kit-rs/query-engine-tests/tests/queries/batch/mod.rs → query-engine/connector-test-kit-rs/query-engine-tests/tests/queries/batching/mod.rs

@@ -1,4 +1,3 @@
-mod in_selection_batching;
 mod select_one_compound;
 mod select_one_singular;
 mod transactional_batch;

query-engine/connector-test-kit-rs/query-engine-tests/tests/queries/batch/in_selection_batching.rs → query-engine/connector-test-kit-rs/query-engine-tests/tests/queries/chunking.rs

@@ -1,8 +1,16 @@
 use query_engine_tests::*;
 
-/// Port note: Batch size for testing is now 10 by default, not configurable (look at the direnv).
+/// * QUERY_BATCH_SIZE for testing is 10, configured in direnv.
+/// * It should be called QUERY_CHUNK_SIZE instead, because it's a knob to configure query chunking
+///  which is splitting queries with more arguments than accepted by the database, in multiple
+///  queries.
+/// * WASM versions of the engine don't accept runtime configuration of this value so they default
+///  the mininum supported by any database on a SQL family (eg. Postgres, MySQL, SQLite, SQL Server,
+///  etc.) As such, in order to guarantee chunking happens, a large number of arguments --larger
+///  than the default-- needs to be used, to have actual coverage of chunking code while exercising
+///  WASM query engines.
 #[test_suite(schema(schema))]
-mod isb {
+mod chunking {
     use indoc::indoc;
     use query_engine_tests::{assert_error, run_query};
 
@@ -34,8 +42,8 @@ mod isb {
         schema.to_owned()
     }
 
-    // "batching of IN queries" should "work when having more than the specified amount of items"
-    // TODO(joins): Excluded because we have no support for batched queries with joins. In practice, it should happen under much less circumstances
+    // "chunking of IN queries" should "work when having more than the specified amount of items"
+    // TODO(joins): Excluded because we have no support for chunked queries with joins. In practice, it should happen under much less circumstances
     // TODO(joins): than with the query-based strategy, because we don't issue `WHERE IN (parent_ids)` queries anymore to resolve relations.
     #[connector_test(exclude_features("relationJoins"))]
     async fn in_more_items(runner: Runner) -> TestResult<()> {
@@ -52,8 +60,8 @@ mod isb {
         Ok(())
     }
 
-    // "ascending ordering of batched IN queries" should "work when having more than the specified amount of items"
-    // TODO(joins): Excluded because we have no support for batched queries with joins. In practice, it should happen under much less circumstances
+    // "ascending ordering of chunked IN queries" should "work when having more than the specified amount of items"
+    // TODO(joins): Excluded because we have no support for chunked queries with joins. In practice, it should happen under much less circumstances
     // TODO(joins): than with the query-based strategy, because we don't issue `WHERE IN (parent_ids)` queries anymore to resolve relations.
     #[connector_test(exclude_features("relationJoins"))]
     async fn asc_in_ordering(runner: Runner) -> TestResult<()> {
@@ -70,8 +78,8 @@ mod isb {
         Ok(())
     }
 
-    // "ascending ordering of batched IN queries" should "work when having more than the specified amount of items"
-    // TODO(joins): Excluded because we have no support for batched queries with joins. In practice, it should happen under much less circumstances
+    // "ascending ordering of chunked IN queries" should "work when having more than the specified amount of items"
+    // TODO(joins): Excluded because we have no support for chunked queries with joins. In practice, it should happen under much less circumstances
     // TODO(joins): than with the query-based strategy, because we don't issue `WHERE IN (parent_ids)` queries anymore to resolve relations.
     #[connector_test(exclude_features("relationJoins"))]
     async fn desc_in_ordering(runner: Runner) -> TestResult<()> {

query-engine/connector-test-kit-rs/query-engine-tests/tests/queries/mod.rs

@@ -1,5 +1,6 @@
 mod aggregation;
-mod batch;
+mod batching;
+mod chunking;
 mod data_types;
 mod distinct;
 mod filters;