import { A as AdapterBackend, F as FenceSql } from '../../../types-BynPp5kU.cjs';
export { h as AdoptedSchemaWriteTransaction, i as FenceStatements, S as SchemaProvisioning, W as WriteFencePlan } from '../../../types-BynPp5kU.cjs';
import { a as SqlEngineProfile } from '../../../profile-DppApFgt.cjs';
export { B as BackendResourceAudit, b as BaseSchemaRuntime, C as ContributionRuntime, E as EngineAssembly, c as EngineProvisioning, d as EngineTableNames, G as GraphTemplateRuntime, I as IdentityRuntime, e as IndexMaterializationRuntime, K as KindRemovalRuntime } from '../../../profile-DppApFgt.cjs';
export { b as buildPostgresEngineProfile } from '../../../postgres-Dp3MpyJt.cjs';
export { b as buildSqliteEngineProfile } from '../../../sqlite-BpRtjC36.cjs';
import 'zod';
import 'drizzle-orm';
import '../../../atomic-mutation-program-DMdmc4s0.cjs';
import '../../../postgres-DOBXcZVg.cjs';
import 'drizzle-orm/pg-core';
import '../../../postgres-execution-fKW0qRiN.cjs';
import 'drizzle-orm/relations';
import '../../../sqlite-execution-DHenxnsc.cjs';
import 'drizzle-orm/sqlite-core';
import '../../../sqlite-BkQM9ZeI.cjs';

/**
 * Assembles one `AdapterBackend` from a {@link SqlEngineProfile}.
 *
 * The write-fence-declaration refusal below is what makes the marking
 * `applyEngineMarks` (`./marks`) performs sound for a profile this factory
 * did not write itself, not only for the two bundled ones: a profile whose
 * resolved capabilities name no `writeFence` is refused outright, because
 * every mark and registration `applyEngineMarks` applies assumes a
 * resolvable write-fence decision, and `resolveWriteFencePlan`'s
 * dialect-derivation fallback is sound only for the two bundled dialects.
 * `applyEngineMarks`'s own doc comment covers its two further gates —
 * `markBundledRootAutocommitEligible` on the profile's `autocommit`
 * declaration, `markSchemaFencedInsertEligible` on the resolved fence plan.
 * A fourth gate, resolved once as `isFirstParty` below and threaded to both
 * `applyEngineMarks` and the fence target this factory builds, decides
 * `markFirstPartyFactory` itself: only the exact profile object
 * `isFirstPartyProfile` (`../../capabilities/write-fence`) recognizes earns
 * that mark, so the dialect-derivation fallback above and the lazy
 * schema-fence lease it feeds stay closed to a profile that merely resembles
 * a bundled one — a copy, spread, or otherwise derived profile is a
 * different object and is never recognized.
 */
declare function createSqlBackend<TTx>(profile: SqlEngineProfile<TTx>): AdapterBackend<TTx>;

/**
 * The `SqlEngineProfile` fields `deriveEngineProfile` can override. Pinned
 * against the full set of profile keys, both directions, by
 * `tests/engine-profile-derivable-keys.test.ts`.
 */
declare const DERIVABLE_ENGINE_PROFILE_KEYS: readonly ["declaredCapabilities", "fenceSql", "resourceAudit", "autocommit", "contributionRuntime", "identityRuntime", "graphTemplateRuntime", "baseSchemaRuntime", "indexMaterializationRuntime", "kindRemovalRuntime", "close"];
/** One of {@link DERIVABLE_ENGINE_PROFILE_KEYS}. */
type DerivableEngineProfileKey = (typeof DERIVABLE_ENGINE_PROFILE_KEYS)[number];
/**
 * The overrides `deriveEngineProfile` accepts. Every field is optional, so a
 * caller only spells the ones it changes.
 *
 * `fenceSql` is spelled separately from the rest so it alone permits an
 * explicit `undefined` — under `exactOptionalPropertyTypes`, a bare
 * `Partial<Pick<...>>` would forbid `undefined` for `fenceSql` exactly as it
 * does for every required field, but `fenceSql` is the one field on
 * `SqlEngineProfile` an author can legitimately want to REMOVE: a derived
 * profile whose engine has no advisory-lock spelling passes
 * `fenceSql: undefined` to drop it rather than leaving the base profile's
 * spelling in place. No other key in the union can be set to `undefined`:
 * each of them is a required field on `SqlEngineProfile`, and clearing one
 * would leave `createSqlBackend` with no value to read at all.
 *
 * Dropping `fenceSql` alone is not enough to reach a working profile:
 * `createSqlBackend` still resolves a write-fence plan eagerly, and a
 * profile whose `declaredCapabilities.writeFence.mechanism` is still
 * `"advisory"` with no `fenceSql` to spell the lock refuses with
 * `WRITE_FENCE_SQL_UNAVAILABLE`. Pairing `fenceSql: undefined` with a
 * `declaredCapabilities` override that also stops claiming `"advisory"`
 * (for example `mechanism: "engine-serialized"`) is what actually removes
 * the spelling successfully; see `tests/engine-profile-derivation.test.ts`.
 */
type DerivableEngineProfileOverrides<TTx> = Partial<Omit<Pick<SqlEngineProfile<TTx>, DerivableEngineProfileKey>, "fenceSql">> & Readonly<{
    fenceSql?: FenceSql | undefined;
}>;
/**
 * Builds a fresh {@link SqlEngineProfile} from `base` with `overrides`
 * applied — `{...base, ...overrides}`, never a mutation of `base`. `base` is
 * meant to be the return value of `buildSqliteEngineProfile` or
 * `buildPostgresEngineProfile`, but this function does not check that: it
 * only enforces that every key `overrides` supplies is one of
 * {@link DERIVABLE_ENGINE_PROFILE_KEYS}.
 *
 * A key outside that set throws `ConfigurationError` with code
 * `ENGINE_PROFILE_OVERRIDE_UNSUPPORTED` naming the key, because the bundled
 * builders bind that field into more than one closure when the profile is
 * built (see the module doc comment): applying the override to the head
 * field alone would leave `buildOperations`, `lateMembers`, or a member
 * group they build reading the value `base` closed over, so some parts of
 * the assembled backend would see the override and others would silently
 * ignore it. The check reads the overrides object's OWN keys (including
 * symbol keys, since `{...base, ...overrides}` below copies those too) at
 * runtime, not only its declared type, so a caller that bypasses the type
 * (e.g. an `as never` cast) is refused exactly the same way.
 *
 * A key inside the derivable set can still be refused: overriding
 * `declaredCapabilities.maxBindParameters`,
 * `declaredCapabilities.execution.interactiveTransactions`, or
 * `resourceAudit.kind` away from `base`'s own value throws the same code,
 * naming the sub-field, for the reason the module doc comment states.
 *
 * The result goes through every `createSqlBackend` gate unchanged, and is
 * never first-party — see the module doc comment for what that costs. Its
 * `assembly` is the SAME object `base.assembly` is: `overrides` can never
 * name that key, so `resolveEngineAssembly` (`./assembly`) resolves the
 * derived profile to the identical `buildOperations`/`lateMembers` pair the
 * base builder closed over.
 */
declare function deriveEngineProfile<TTx>(base: SqlEngineProfile<TTx>, overrides: DerivableEngineProfileOverrides<TTx>): SqlEngineProfile<TTx>;

export { DERIVABLE_ENGINE_PROFILE_KEYS, type DerivableEngineProfileKey, type DerivableEngineProfileOverrides, SqlEngineProfile, createSqlBackend, deriveEngineProfile };