# deriveDataLayer() function · @imqueue/pg-prisma

Source: https://imqueue.org/api/pg-prisma/latest/pg-prisma.derivedatalayer/
Published: 2026-08-28
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/pg-prisma 2.0.0 — generated reference, not hand-written

Derive the data-layer config from an emitted contract.

**Signature:**

```typescript
export declare function deriveDataLayer(input: DeriveOptions): DerivedDataLayer;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| input | [DeriveOptions](https://imqueue.org/api/pg-prisma/latest/pg-prisma.deriveoptions/) |  |


**Returns:**

[DerivedDataLayer](https://imqueue.org/api/pg-prisma/latest/pg-prisma.deriveddatalayer/)

Config for [dataLayer()](https://imqueue.org/api/pg-prisma/latest/pg-prisma.datalayer_1/) and the individual middlewares.

## Exceptions

When `scope` names a model the contract does not define.

## Remarks

This replaces the Prisma 7 generator that wrote `SOFT_DELETE_MODELS`, `AUTHORSHIP_MODELS` and the rest into `src/generated`. Prisma Next has no custom-generator protocol and does not need one: the contract already names every model, field and physical column, so the same config is a lookup rather than a build step, and nothing can go stale against the schema.

Membership is by convention, which is what `softDelete = "auto"` and `authorship = "auto"` meant. Everything is keyed by \*\*physical table\*\*, because that is what a statement names — resolving a table back to a model at query time would have to go through the contract's `roots`, which is keyed by bare table name only while that name is unique across namespaces.

## Example


```typescript
const layer = deriveDataLayer({
    contract: contractJson,
    scope: { Portfolio: { portfolio: ['id'] } },
});
```