@vantreeseba/drizzle-graphql 6.0.0 → 7.0.0

package/dist/index.d.cts

@@ -232,8 +232,14 @@ declare const drizzleExecutorKey: unique symbol;
  *   2. When limit/offset args are present, falls back to a direct per-item query.
  *   3. Otherwise batches all sibling resolver calls within the same GraphQL execution tick
  *      into a single IN-clause query, eliminating N+1 database round-trips.
+ *
+ * `nullOrdering` is the dialect's native `ORDER BY` placement for `NULL` — the keyset
+ * predicate behind a relation's `after` argument has to match it, or rows with a `NULL` in an
+ * ordered column would be skipped instead of paged through. It has no sensible default, so
+ * each dialect builder states it: `'nulls-largest'` for PostgreSQL, `'nulls-smallest'` for
+ * MySQL and SQLite.
  */
-declare const createRelationResolverFactory: (db: any, tables: Record<string, Table>, filterCtx?: RelationFilterBase) => RelationResolverFactory;
+declare const createRelationResolverFactory: (db: any, tables: Record<string, Table>, nullOrdering: NullOrdering, filterCtx?: RelationFilterBase) => RelationResolverFactory;
 /**
  * Compiles an `orderBy` argument into ORDER BY expressions, highest priority first.
  *
@@ -275,6 +281,14 @@ interface RelationFilterContext {
  */
 type RelationFilterBase = Pick<RelationFilterContext, 'tables' | 'relationMap'>;
 declare const extractFilters: <TTable extends Table>(table: TTable, tableName: string, filters: Filters<TTable>, relationCtx?: RelationFilterContext) => SQL | undefined;
+/**
+ * Where a dialect's default sort places NULLs relative to non-NULL values:
+ * - `nulls-largest` — PostgreSQL: NULLs sort as the largest values (last in ASC, first in DESC).
+ * - `nulls-smallest` — MySQL and SQLite: NULLs sort as the smallest values (first in ASC, last
+ *   in DESC).
+ * The keyset predicate has to agree with the dialect's ORDER BY, so each builder passes its own.
+ */
+type NullOrdering = 'nulls-largest' | 'nulls-smallest';
 /**
  * Default for `config.onError`: keeps drizzle-graphql's own errors, which are written for
  * the client, and replaces driver/database errors with a generic message. Their text names
@@ -669,6 +683,51 @@ type SchemaFeatures = {
      * @default false
      */
     nestedWrites?: boolean;
+    /**
+     * Operation inputs on the update `set`, so a column can be changed relative to its current
+     * value instead of only replaced.
+     *
+     * ```graphql
+     * updatePostsSingle(where: { id: { eq: "p1" } }, set: { views: { increment: 1 } }) { views }
+     * ```
+     *
+     * Every numeric column's field on `Update<Table>Input` becomes a `<Scalar>FieldUpdate`
+     * input carrying `set`, `increment`, `decrement`, `multiply` and `divide`; every array
+     * column's becomes a `<Scalar>ListFieldUpdate` carrying `set` and `push`. Exactly one
+     * operation per field, checked at resolve time. `set` is the explicit spelling of what the
+     * field did before, so `set: { views: 42 }` becomes `set: { views: { set: 42 } }`.
+     *
+     * The arithmetic happens in the database (`SET views = views + 1`), so a counter no longer
+     * needs a read-modify-write round trip and no longer loses concurrent updates. Rounding on
+     * an integer column, and division by zero, follow the database's own rules rather than
+     * being guarded here. Columns owned by a scalar override keep their plain type — an
+     * override owns what the column accepts.
+     *
+     * Off by default: it changes the type of every numeric and array field on every update
+     * input, which no existing document is written against.
+     *
+     * @default false
+     */
+    fieldUpdateOperations?: boolean;
+    /**
+     * `update<Table>Count` / `delete<Table>Count` mutations — the same write as the plural
+     * `update<Table>` / `delete<Table>`, returning the number of rows affected instead of the
+     * rows themselves.
+     *
+     * ```graphql
+     * deletePostsCount(where: { published: { eq: false } })   # Int!
+     * ```
+     *
+     * A mass update or delete otherwise has to `RETURNING *` every row it touched purely so
+     * the caller can count them, which crosses the driver and is serialized through GraphQL
+     * for nothing. Each mutation is generated only when its plural counterpart is
+     * (`features.update` / `features.delete`), and honours `features.requireWhere`.
+     *
+     * Off unless asked for, so an existing schema does not grow new mutations on upgrade.
+     *
+     * @default false
+     */
+    countMutations?: boolean;
     /**
      * Makes `where` non-null on the plural `update<Table>` / `delete<Table>` mutations, and
      * rejects a `where` that collapses to no filters (e.g. `where: {}`), so a schema can rule

package/dist/index.d.ts

@@ -232,8 +232,14 @@ declare const drizzleExecutorKey: unique symbol;
  *   2. When limit/offset args are present, falls back to a direct per-item query.
  *   3. Otherwise batches all sibling resolver calls within the same GraphQL execution tick
  *      into a single IN-clause query, eliminating N+1 database round-trips.
+ *
+ * `nullOrdering` is the dialect's native `ORDER BY` placement for `NULL` — the keyset
+ * predicate behind a relation's `after` argument has to match it, or rows with a `NULL` in an
+ * ordered column would be skipped instead of paged through. It has no sensible default, so
+ * each dialect builder states it: `'nulls-largest'` for PostgreSQL, `'nulls-smallest'` for
+ * MySQL and SQLite.
  */
-declare const createRelationResolverFactory: (db: any, tables: Record<string, Table>, filterCtx?: RelationFilterBase) => RelationResolverFactory;
+declare const createRelationResolverFactory: (db: any, tables: Record<string, Table>, nullOrdering: NullOrdering, filterCtx?: RelationFilterBase) => RelationResolverFactory;
 /**
  * Compiles an `orderBy` argument into ORDER BY expressions, highest priority first.
  *
@@ -275,6 +281,14 @@ interface RelationFilterContext {
  */
 type RelationFilterBase = Pick<RelationFilterContext, 'tables' | 'relationMap'>;
 declare const extractFilters: <TTable extends Table>(table: TTable, tableName: string, filters: Filters<TTable>, relationCtx?: RelationFilterContext) => SQL | undefined;
+/**
+ * Where a dialect's default sort places NULLs relative to non-NULL values:
+ * - `nulls-largest` — PostgreSQL: NULLs sort as the largest values (last in ASC, first in DESC).
+ * - `nulls-smallest` — MySQL and SQLite: NULLs sort as the smallest values (first in ASC, last
+ *   in DESC).
+ * The keyset predicate has to agree with the dialect's ORDER BY, so each builder passes its own.
+ */
+type NullOrdering = 'nulls-largest' | 'nulls-smallest';
 /**
  * Default for `config.onError`: keeps drizzle-graphql's own errors, which are written for
  * the client, and replaces driver/database errors with a generic message. Their text names
@@ -669,6 +683,51 @@ type SchemaFeatures = {
      * @default false
      */
     nestedWrites?: boolean;
+    /**
+     * Operation inputs on the update `set`, so a column can be changed relative to its current
+     * value instead of only replaced.
+     *
+     * ```graphql
+     * updatePostsSingle(where: { id: { eq: "p1" } }, set: { views: { increment: 1 } }) { views }
+     * ```
+     *
+     * Every numeric column's field on `Update<Table>Input` becomes a `<Scalar>FieldUpdate`
+     * input carrying `set`, `increment`, `decrement`, `multiply` and `divide`; every array
+     * column's becomes a `<Scalar>ListFieldUpdate` carrying `set` and `push`. Exactly one
+     * operation per field, checked at resolve time. `set` is the explicit spelling of what the
+     * field did before, so `set: { views: 42 }` becomes `set: { views: { set: 42 } }`.
+     *
+     * The arithmetic happens in the database (`SET views = views + 1`), so a counter no longer
+     * needs a read-modify-write round trip and no longer loses concurrent updates. Rounding on
+     * an integer column, and division by zero, follow the database's own rules rather than
+     * being guarded here. Columns owned by a scalar override keep their plain type — an
+     * override owns what the column accepts.
+     *
+     * Off by default: it changes the type of every numeric and array field on every update
+     * input, which no existing document is written against.
+     *
+     * @default false
+     */
+    fieldUpdateOperations?: boolean;
+    /**
+     * `update<Table>Count` / `delete<Table>Count` mutations — the same write as the plural
+     * `update<Table>` / `delete<Table>`, returning the number of rows affected instead of the
+     * rows themselves.
+     *
+     * ```graphql
+     * deletePostsCount(where: { published: { eq: false } })   # Int!
+     * ```
+     *
+     * A mass update or delete otherwise has to `RETURNING *` every row it touched purely so
+     * the caller can count them, which crosses the driver and is serialized through GraphQL
+     * for nothing. Each mutation is generated only when its plural counterpart is
+     * (`features.update` / `features.delete`), and honours `features.requireWhere`.
+     *
+     * Off unless asked for, so an existing schema does not grow new mutations on upgrade.
+     *
+     * @default false
+     */
+    countMutations?: boolean;
     /**
      * Makes `where` non-null on the plural `update<Table>` / `delete<Table>` mutations, and
      * rejects a `where` that collapses to no filters (e.g. `where: {}`), so a schema can rule