pastilhas
c892f2e700
the extraction kept atelier's own postgres database, because the brief said to when the tables already had rows. the owner reversed it, and the reason is not tidiness: a plugin that behaves differently from every other plugin is a plugin nobody can reason about. the separate database meant a second connection string to set before install, a second thing to back up, a second thing to get wrong on a new machine, and failure modes no other plugin shares — none of it bought anything except avoiding a migration. four tables now: atelier_collections, atelier_collection_items, atelier_providers, atelier_generations. index and check constraint names carry the prefix too — those are global in postgres and are the one thing that would otherwise collide with another plugin. db/schema.ts re-exports the definitions rather than duplicating them: they stay beside the code that queries them in sidecar/db/, and that file exists to be found by gen-plugin-schemas. ATELIER_POSTGRES_URL is gone. db.ts reads OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL, which the platform already sets. the standalone service's rows are NOT here and nothing depends on them being here — the old service is still running against the old database, untouched, and migrating is a separate watched step after this is proven on alpha.
16 lines
1.0 KiB
TypeScript
16 lines
1.0 KiB
TypeScript
// The plugin's tables, where the platform looks for them.
|
|
//
|
|
// `scripts/gen-plugin-schemas.ts` writes `plugin-schemas.gen.ts` from every plugin's `db/schema.ts`, and
|
|
// that generated barrel is what `bun db:push` reads. So this file exists to be FOUND — the definitions
|
|
// themselves live beside the code that queries them, in `sidecar/db/`, and are re-exported here rather
|
|
// than duplicated.
|
|
//
|
|
// Everything is `atelier_`-prefixed and lives in officer_db, exactly like every other plugin. The
|
|
// extraction originally kept Atelier's own `atelier` database, on the reasoning that its tables already
|
|
// had rows. That was reversed on 2026-08-20: the plugin starts EMPTY here, and the standalone service's
|
|
// data is migrated deliberately afterwards, with someone watching. A plugin that behaves differently
|
|
// from every other plugin is a plugin nobody can reason about.
|
|
export * from '../sidecar/db/collections/schema';
|
|
export * from '../sidecar/db/generations/schema';
|
|
export * from '../sidecar/db/providers/schema';
|