@siftlite/drizzle

Optional Drizzle companion. It maps public Drizzle table metadata into canonical SiftLite IndexDefinition values.

This package does not own index synchronization. Linked indexes stay correct when writes go through Drizzle or raw SQL because database triggers maintain FTS state.

Supported metadata surface (tested on [email protected]):

• getTableName
• getTableColumns
• column name, dataType, columnType, timestamp mode

import { defineDrizzleIndex, drizzleSearch } from "@siftlite/drizzle";
import { products } from "./schema";

export const productsSearch = defineDrizzleIndex(products, {
  id: products.id,
  normalization: ["arabic-basic"],
  searchable: {
    name: { weight: 5 },
    description: { weight: 1 },
  },
  filterable: {
    status: products.status,
    price: products.price,
  },
});

const results = await drizzleSearch(db, productsSearch, adapter).search("iphone", {
  hydrate: true,
});

Unsupported Drizzle types (blob, bigint, JSON blobs) fail at definition time. Timestamp columns use Drizzle's explicit timestamp / timestamp_ms mode; generic integers are not guessed to be dates.

Companion SQL is a deterministic migration fragment:

const migration = generateDrizzleSearchSql(productsSearch);

generateDrizzleSearchSql forwards compileIndexLifecycleSql, so the fragment creates the physical objects and seeds a pending registry row. Applying the fragment alone is not enough: run createIndex once with the same definition to verify the objects and mark that row healthy. An intact pending generation is reused; incomplete objects may be rematerialized during recovery. A later call against an already-healthy row fails with SEARCH_CONFIG_INVALID / already-exists.

When typoTolerance.mode: "fallback", companion SQL also emits the trigram FTS table; integrity checks require it. Runtime createIndex remains the recommended path for materializing and finalizing the registry.

Canonical escape hatch:

productsSearch.definition;