@vsrepo/prisma7-adapter 1.0.1 → 1.0.3

package/README.md

@@ -236,6 +236,36 @@ await userRepository.transaction(async tx => {
 });
 ```
 
+### Concurrency in `deleteManyReturning`
+
+`deleteManyReturning` runs a `findMany` on the given `where` (to capture the records it will return) and then **re-applies the same `where`** to a `deleteMany`. Prisma has no native `deleteManyAndReturn`, which is why the delete is driven by the `where` instead of by the records fetched in the `findMany`.
+
+Because of this two-step shape, a concurrent change between the `findMany` and the `deleteMany` can make them diverge:
+
+- a row **inserted after** the `findMany` that matches the `where` will still be deleted, even though it wasn't returned;
+- a row that **stops matching** the `where` before the `deleteMany` runs won't be deleted, even though it was returned.
+
+In other words, the returned records and the rows actually deleted are not guaranteed to be identical under concurrency.
+
+If you need to guarantee there are no concurrency issues, run this method inside a `repository.transaction()` at a higher isolation level — e.g. `SERIALIZABLE`:
+
+```typescript
+import { VSRepository, TransactionIsolationLevel } from "vsrepo";
+
+await userRepository.transaction(async tx => {
+    // Atomic: no concurrent insert/update can slip between the findMany
+    // and the deleteMany, since SERIALIZABLE isolates this transaction.
+    // `deleteManyReturning` is reached through the dynamic method you mapped
+    // to the adapter (e.g. a `@DynamicMethod()` exposing `deleteManyReturning`),
+    // always passing `{ db: tx }` so it runs inside this transaction.
+    const deleted = await userRepository.deleteManyReturningByIdIn([...], { db: tx });
+}, {
+    isolationLevel: TransactionIsolationLevel.SERIALIZABLE,
+});
+```
+
+> The isolation level applies only when the repository call actually runs **inside** that transaction (i.e. with `{ db: tx }`). When `deleteManyReturning` starts its own internal transaction (no `options.db` passed), it falls back to the default isolation level.
+
 ## Logging
 
 The adapter uses `VSLogger` (from `vsrepo`) internally: every method logs a `DEBUG` line with the resolved Prisma arg, and start/end performance logs (surfacing a `WARN` for slow operations). Set `logLevel` in the constructor config to control verbosity; it defaults to `VSLogLevel.WARN`.

package/README.pt-BR.md

@@ -236,6 +236,36 @@ await userRepository.transaction(async tx => {
 });
 ```
 
+### Concorrência em `deleteManyReturning`
+
+O `deleteManyReturning` roda um `findMany` no `where` informado (pra capturar os registros que vai devolver) e depois **re-aplica o mesmo `where`** num `deleteMany`. Como o Prisma não tem um `deleteManyAndReturn` nativo, o delete é guiado pelo `where` — e não pelos registros retornados no `findMany`.
+
+Por causa desse formato em duas etapas, uma alteração concorrente entre o `findMany` e o `deleteMany` pode fazer os dois divergirem:
+
+- uma linha **inserida depois** do `findMany` que bate com o `where` ainda será deletada, mesmo não tendo sido retornada;
+- uma linha que **deixa de bater** com o `where` antes do `deleteMany` rodar não será deletada, mesmo tendo sido retornada.
+
+Ou seja: os registros retornados e as linhas realmente deletadas não têm garantia de serem idênticos sob concorrência.
+
+Se você quiser garantir que não haverá problemas de concorrência, rode esse método **dentro** de um `repository.transaction()` num nível de isolamento mais alto — ex.: `SERIALIZABLE`:
+
+```typescript
+import { VSRepository, TransactionIsolationLevel } from "vsrepo";
+
+await userRepository.transaction(async tx => {
+    // Atômico: nenhum insert/update concorrente consegue entrar entre o
+    // findMany e o deleteMany, pois o SERIALIZABLE isola esta transaction.
+    // O `deleteManyReturning` é acessado através do método dinâmico que você
+    // mapeou pro adapter (ex.: um `@DynamicMethod()` expondo `deleteManyReturning`),
+    // sempre passando `{ db: tx }` pra rodar dentro desta transaction.
+    const deleted = await userRepository.deleteManyReturningByIdIn([...], { db: tx });
+}, {
+    isolationLevel: TransactionIsolationLevel.SERIALIZABLE,
+});
+```
+
+> O nível de isolamento só se aplica quando a chamada roda **dentro** daquela transaction (ou seja, com `{ db: tx }`). Quando o `deleteManyReturning` inicia a própria transaction interna (sem `options.db`), ele usa o nível de isolamento padrão.
+
 ## Logging
 
 O adapter usa o `VSLogger` (de `vsrepo`) internamente: todo método loga uma linha `DEBUG` com o arg resolvido do Prisma, além de logs de performance de início/fim (com `WARN` pra operações lentas). Configure `logLevel` na config do construtor pra controlar a verbosidade; o default é `VSLogLevel.WARN`.

package/dist/prisma7.adapter.d.ts

@@ -79,10 +79,18 @@ export declare class VSRepoPrisma7Adapter<T> extends VSRepoAdapter<T> {
     deleteMany(where: VSRepoWhere<T>, options?: AdapterMethodOptions<T>): Promise<CountResult>;
     /**
      * Deletes every record matching `where`, returning the deleted records.
-     * Prisma has no `deleteManyAndReturn`, so this fetches then deletes inside
-     * a transaction — reusing `options.db` when it's already a transaction
-     * client (see `runTransactional`), so it stays atomic even when it's not
-     * the one starting the transaction.
+     *
+     * Prisma has no `deleteManyAndReturn`, so this does a `findMany` on
+     * `where` first and then re-applies the same `where` to a `deleteMany`,
+     * both inside a transaction (`runTransactional`).
+     *
+     * Because the delete is driven by the same `where` (not by the fetched
+     * records), a concurrent change between the two operations can make them
+     * diverge — e.g. a row inserted after the `findMany` matching the `where`
+     * would still be deleted, while a row changed to stop matching wouldn't.
+     * If you need to guarantee no concurrency issues, run this method inside a
+     * `repository.transaction()` with a higher isolation level, e.g.
+     * `TransactionIsolationLevel.SERIALIZABLE`.
      */
     deleteManyReturning(where: VSRepoWhere<T>, options?: AdapterMethodOptions<T>): Promise<T[]>;
     /** Updates a single record matching `where`. */

package/dist/prisma7.adapter.js

@@ -40,7 +40,7 @@ class VSRepoPrisma7Adapter extends vsrepo_1.VSRepoAdapter {
         this.tableName = validated.tableName;
         this.pkName = validated.pkName;
         this.relations = validated.relations;
-        this.logger = new vsrepo_1.VSLogger(validated.logLevel ?? vsrepo_1.VSLogLevel.WARN, this.constructor.name + "Logger", validated.logSlowThresholdMs);
+        this.logger = new vsrepo_1.VSLogger(validated.logLevel ?? vsrepo_1.VSLogLevel.WARN, this.constructor.name + "Logger", validated.logSlowThresholdMs ?? 300);
         this.logger.logInfo(`${this.constructor.name} initialized for table '${this.tableName}' (pkName: '${this.pkName}'${this.relations ? `, relations: [${Object.keys(this.relations).join(", ")}]` : ""})`);
     }
     getPrismaRepository(db) {
@@ -241,10 +241,18 @@ class VSRepoPrisma7Adapter extends vsrepo_1.VSRepoAdapter {
     }
     /**
      * Deletes every record matching `where`, returning the deleted records.
-     * Prisma has no `deleteManyAndReturn`, so this fetches then deletes inside
-     * a transaction — reusing `options.db` when it's already a transaction
-     * client (see `runTransactional`), so it stays atomic even when it's not
-     * the one starting the transaction.
+     *
+     * Prisma has no `deleteManyAndReturn`, so this does a `findMany` on
+     * `where` first and then re-applies the same `where` to a `deleteMany`,
+     * both inside a transaction (`runTransactional`).
+     *
+     * Because the delete is driven by the same `where` (not by the fetched
+     * records), a concurrent change between the two operations can make them
+     * diverge — e.g. a row inserted after the `findMany` matching the `where`
+     * would still be deleted, while a row changed to stop matching wouldn't.
+     * If you need to guarantee no concurrency issues, run this method inside a
+     * `repository.transaction()` with a higher isolation level, e.g.
+     * `TransactionIsolationLevel.SERIALIZABLE`.
      */
     async deleteManyReturning(where, options) {
         const start = this.logger.startPerformLog("run deleteManyReturning");

package/dist/validators/adapter-config.schema.d.ts

@@ -10,4 +10,5 @@ export declare const adapterConfigSchema: v.ObjectSchema<{
         readonly nullable: v.OptionalSchema<v.BooleanSchema<undefined>, undefined>;
     }, undefined>, undefined>, undefined>;
     readonly logLevel: v.OptionalSchema<v.EnumSchema<typeof VSLogLevel, undefined>, undefined>;
+    readonly logSlowThresholdMs: v.OptionalSchema<v.SchemaWithPipe<readonly [v.NumberSchema<undefined>, v.GtValueAction<number, 0, undefined>]>, undefined>;
 }, undefined>;

package/dist/validators/adapter-config.schema.js

@@ -42,4 +42,5 @@ exports.adapterConfigSchema = v.object({
     pkName: v.pipe(v.string(), v.minLength(1)),
     relations: v.optional(v.record(v.string(), relation_schema_1.relationSchema)),
     logLevel: v.optional(v.enum(vsrepo_1.VSLogLevel)),
+    logSlowThresholdMs: v.optional(v.pipe(v.number(), v.gtValue(0))),
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vsrepo/prisma7-adapter",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "VSRepository adapter implementation backed by Prisma 7, translating every VSRepository operation into Prisma Client calls.",
   "homepage": "https://github.com/jaobrabo123/VSRepoPrisma7Adapter#readme",
   "repository": {