From b2e0992ff6dfd1fc250532012d9a8cb7affb48a8 Mon Sep 17 00:00:00 2001 From: Preston Date: Tue, 3 Mar 2026 12:23:18 -0600 Subject: [PATCH 1/2] Added warning section for using ignoreConflicts with models the have non-persistant fields. --- docs/06-concepts/06-database/05-crud.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/06-concepts/06-database/05-crud.md b/docs/06-concepts/06-database/05-crud.md index fdbde880..6b5be3ee 100644 --- a/docs/06-concepts/06-database/05-crud.md +++ b/docs/06-concepts/06-database/05-crud.md @@ -60,6 +60,10 @@ This is useful for idempotent operations where you want to insert data without f Under the hood, this uses PostgreSQL's `ON CONFLICT DO NOTHING`. Only unique and exclusion constraint violations are ignored — other errors such as `NOT NULL`, `CHECK`, or foreign key violations will still throw an exception. ::: +:::warning +When using `ignoreConflicts` with models that have non-persistent fields, each row is inserted individually instead of in a single batch. This is necessary because the database cannot report which rows were skipped in a batch insert, making it impossible to correctly match non-persistent field values back to inserted rows. For large numbers of rows, this can cause performance issues. Consider removing non-persistent fields from the model or inserting in smaller batches. +::: + ## Read There are three different read operations available. From 9f096e68d054f930cd342b13ac85f95c4ee7857f Mon Sep 17 00:00:00 2001 From: Preston Date: Tue, 3 Mar 2026 12:30:16 -0600 Subject: [PATCH 2/2] Implemented co-pilot suggestions. --- docs/06-concepts/06-database/05-crud.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/06-concepts/06-database/05-crud.md b/docs/06-concepts/06-database/05-crud.md index 6b5be3ee..d70a34f2 100644 --- a/docs/06-concepts/06-database/05-crud.md +++ b/docs/06-concepts/06-database/05-crud.md @@ -45,14 +45,14 @@ In previous versions of Serverpod the `insert` method mutated the input object b ### Ignoring conflicts -When inserting rows that might violate a unique or exclusion constraint, you can set `ignoreConflicts` to `true` on the `insert` method. Rows that would cause a unique constraint violation are silently skipped, and only the non-conflicting rows are inserted. +When inserting rows that might violate a unique or exclusion constraint, you can set `ignoreConflicts` to `true` on the `insert` method. Rows that would cause a unique or exclusion constraint violation are silently skipped, and only the non-conflicting rows are inserted. ```dart var rows = [Company(name: 'Serverpod'), Company(name: 'Google')]; var inserted = await Company.db.insert(session, rows, ignoreConflicts: true); ``` -The method returns only the rows that were successfully inserted. If all rows conflict, an empty list is returned. +The method returns only the rows that were successfully inserted. If all rows conflict, an empty list is returned. Unlike a regular `insert`, which fails entirely if any row violates a constraint, `ignoreConflicts` allows partial inserts where only the non-conflicting rows are written. This is useful for idempotent operations where you want to insert data without failing on duplicates. @@ -61,7 +61,7 @@ Under the hood, this uses PostgreSQL's `ON CONFLICT DO NOTHING`. Only unique and ::: :::warning -When using `ignoreConflicts` with models that have non-persistent fields, each row is inserted individually instead of in a single batch. This is necessary because the database cannot report which rows were skipped in a batch insert, making it impossible to correctly match non-persistent field values back to inserted rows. For large numbers of rows, this can cause performance issues. Consider removing non-persistent fields from the model or inserting in smaller batches. +When using `ignoreConflicts` with models that have [non-persistent fields](models#non-persistent-fields), each row is inserted individually instead of in a single batch. This is necessary because the database cannot report which rows were skipped in a batch insert, making it impossible to correctly match non-persistent field values back to inserted rows. For large numbers of rows, this can cause performance issues. Consider removing non-persistent fields from the model or inserting in smaller batches. ::: ## Read