@nextlyhq/adapter-drizzle 0.0.2-alpha.48 → 0.0.2-alpha.50

package/dist/{adapter-DJtzp_R8.d.ts → adapter-C-DmzBg8.d.ts}

@@ -2,7 +2,7 @@ import { AnyRelations, SQL } from 'drizzle-orm';
 import { S as SupportedDialect, a as SqlParam, T as TableResolver } from './core-CVO7WYDj.js';
 import { T as TransactionContext, e as TransactionOptions, D as DatabaseCapabilities, P as PoolStats, S as SelectOptions, I as InsertOptions, W as WhereClause, U as UpdateOptions, f as DeleteOptions, g as UpsertOptions, a as Migration, d as MigrationResult } from './migration-Bj84e15B.js';
 import { T as TableDefinition, C as CreateTableOptions, D as DropTableOptions, A as AlterTableOperation, a as AlterTableOptions } from './schema-BIQ0YQZ_.js';
-import { D as DatabaseErrorKind, a as DatabaseError } from './error-um1d_3Uo.js';
+import { D as DatabaseErrorKind, a as DatabaseError } from './error-BrdknH2s.js';
 
 /**
  * Base database adapter abstract class.
@@ -60,11 +60,29 @@ declare abstract class DrizzleAdapter {
      * The transaction is automatically committed on success or rolled back on error.
      * Supports nested transactions via savepoints on databases that support them.
      *
+     * Two kinds of error leave this method, and a caller has to be able to tell
+     * them apart. An error carrying the Nextly application brand — see
+     * `isApplicationError` — arrives exactly as it was thrown, because that is
+     * the application refusing the write rather than the database failing to
+     * perform it, and rewriting it would discard the code and payload the caller
+     * is meant to act on.
+     *
+     * Everything else arrives as a `DatabaseError` with its kind classified, and
+     * that deliberately includes an unbranded error the callback itself threw:
+     * the brand is the only thing distinguishing a deliberate refusal from a
+     * driver failure that surfaced through callback code, and guessing from the
+     * throw site would put raw driver text on the wire under a caller's own
+     * error shape.
+     *
+     * The rollback is the same either way.
+     *
      * @param callback - Function to execute within transaction
      * @param options - Transaction options
      * @returns Result from the callback
      *
-     * @throws {DatabaseError} If transaction fails
+     * @throws {DatabaseError} If the transaction itself fails, or if the callback
+     * threw an error that does not carry the application brand
+     * @throws The callback's own error, unchanged, when it carries that brand
      */
     abstract transaction<T>(callback: (ctx: TransactionContext) => Promise<T>, options?: TransactionOptions): Promise<T>;
     /**

package/dist/{adapter-Ch_5ecmp.d.cts → adapter-CZUQ2aV4.d.cts}

@@ -2,7 +2,7 @@ import { AnyRelations, SQL } from 'drizzle-orm';
 import { S as SupportedDialect, a as SqlParam, T as TableResolver } from './core-CVO7WYDj.cjs';
 import { T as TransactionContext, e as TransactionOptions, D as DatabaseCapabilities, P as PoolStats, S as SelectOptions, I as InsertOptions, W as WhereClause, U as UpdateOptions, f as DeleteOptions, g as UpsertOptions, a as Migration, d as MigrationResult } from './migration-BUc56kip.cjs';
 import { T as TableDefinition, C as CreateTableOptions, D as DropTableOptions, A as AlterTableOperation, a as AlterTableOptions } from './schema-BDn8WfSL.cjs';
-import { D as DatabaseErrorKind, a as DatabaseError } from './error-um1d_3Uo.cjs';
+import { D as DatabaseErrorKind, a as DatabaseError } from './error-BrdknH2s.cjs';
 
 /**
  * Base database adapter abstract class.
@@ -60,11 +60,29 @@ declare abstract class DrizzleAdapter {
      * The transaction is automatically committed on success or rolled back on error.
      * Supports nested transactions via savepoints on databases that support them.
      *
+     * Two kinds of error leave this method, and a caller has to be able to tell
+     * them apart. An error carrying the Nextly application brand — see
+     * `isApplicationError` — arrives exactly as it was thrown, because that is
+     * the application refusing the write rather than the database failing to
+     * perform it, and rewriting it would discard the code and payload the caller
+     * is meant to act on.
+     *
+     * Everything else arrives as a `DatabaseError` with its kind classified, and
+     * that deliberately includes an unbranded error the callback itself threw:
+     * the brand is the only thing distinguishing a deliberate refusal from a
+     * driver failure that surfaced through callback code, and guessing from the
+     * throw site would put raw driver text on the wire under a caller's own
+     * error shape.
+     *
+     * The rollback is the same either way.
+     *
      * @param callback - Function to execute within transaction
      * @param options - Transaction options
      * @returns Result from the callback
      *
-     * @throws {DatabaseError} If transaction fails
+     * @throws {DatabaseError} If the transaction itself fails, or if the callback
+     * threw an error that does not carry the application brand
+     * @throws The callback's own error, unchanged, when it carries that brand
      */
     abstract transaction<T>(callback: (ctx: TransactionContext) => Promise<T>, options?: TransactionOptions): Promise<T>;
     /**

package/dist/{error-um1d_3Uo.d.cts → error-BrdknH2s.d.cts}

@@ -64,6 +64,23 @@ interface DatabaseError extends Error {
  * @public
  */
 declare function isDatabaseError(error: unknown): error is DatabaseError;
+/**
+ * Whether an error is the application's verdict rather than the database's
+ * failure.
+ *
+ * Work running inside a transaction may throw to roll the write back — a
+ * refused value, a permission denial — and such an error is not something the
+ * driver produced. Classifying it as a database error replaces its code and its
+ * payload with a generic one, so a caller that asked for a refusal is handed an
+ * unexplained failure instead, and per-field validation detail is lost on the
+ * way out.
+ *
+ * @param error - Error to check
+ * @returns True if the error was raised by application code
+ *
+ * @public
+ */
+declare function isApplicationError(error: unknown): boolean;
 /**
  * Database error constructor options.
  *
@@ -102,4 +119,4 @@ interface DatabaseErrorOptions {
  */
 declare function createDatabaseError(options: DatabaseErrorOptions): DatabaseError;
 
-export { type DatabaseErrorKind as D, type DatabaseError as a, type DatabaseErrorOptions as b, createDatabaseError as c, isDatabaseError as i };
+export { type DatabaseErrorKind as D, type DatabaseError as a, type DatabaseErrorOptions as b, createDatabaseError as c, isDatabaseError as d, isApplicationError as i };

package/dist/{error-um1d_3Uo.d.ts → error-BrdknH2s.d.ts}

@@ -64,6 +64,23 @@ interface DatabaseError extends Error {
  * @public
  */
 declare function isDatabaseError(error: unknown): error is DatabaseError;
+/**
+ * Whether an error is the application's verdict rather than the database's
+ * failure.
+ *
+ * Work running inside a transaction may throw to roll the write back — a
+ * refused value, a permission denial — and such an error is not something the
+ * driver produced. Classifying it as a database error replaces its code and its
+ * payload with a generic one, so a caller that asked for a refusal is handed an
+ * unexplained failure instead, and per-field validation detail is lost on the
+ * way out.
+ *
+ * @param error - Error to check
+ * @returns True if the error was raised by application code
+ *
+ * @public
+ */
+declare function isApplicationError(error: unknown): boolean;
 /**
  * Database error constructor options.
  *
@@ -102,4 +119,4 @@ interface DatabaseErrorOptions {
  */
 declare function createDatabaseError(options: DatabaseErrorOptions): DatabaseError;
 
-export { type DatabaseErrorKind as D, type DatabaseError as a, type DatabaseErrorOptions as b, createDatabaseError as c, isDatabaseError as i };
+export { type DatabaseErrorKind as D, type DatabaseError as a, type DatabaseErrorOptions as b, createDatabaseError as c, isDatabaseError as d, isApplicationError as i };