Removes all MJ entity metadata associated with an app's schema.
Two teardown strategies, chosen by options:
FK-graph cascade (any provider dialect) — when options.DatabaseProvider is set:
enumerates the live FK graph and clears every one of Entity's dependents set-based,
deepest-first, in one atomic transaction (RunFkGraphTeardown), on BOTH SQL Server and
PostgreSQL (quoting + the FK-graph catalog query come from the provider's SQLDialect). This
covers dependents the entity-layer path under-deletes (base-view joins hide FK-enforced rows).
Entity-layer (no-provider fallback only) — the legacy hardcoded-list + per-entity
Delete() inside ONE TransactionGroup, committed once (all-or-nothing, PG3). Under-deletes
(misses dependents like RecordChange), so it exists only for 2-arg callers that pass no
provider; pass a DatabaseProvider to get the complete cascade.
NOTE: the FK-graph path executes raw set-based SQL — it does NOT go through the BaseEntity
pipeline, so it emits no RecordChange audit rows, fires no *EntityServer delete hooks, and
(most importantly) fires no BaseEntity events, so provider/engine metadata caches are NOT
invalidated. Fine for mj app remove (the CLI process exits), but a caller invoking this inside
a long-running process should refresh metadata afterward. See RunFkGraphTeardown.
In BOTH paths the app-owned Application rows — the link-detected set unioned with the
migration-declared set — are dropped after teardown (so a re-install's fixed-UUID
spCreateApplication doesn't PK-collide). Exported for unit testing of the atomic-transaction
semantics (PG3).
Removes all MJ entity metadata associated with an app's schema.
Two teardown strategies, chosen by
options:options.DatabaseProvideris set: enumerates the live FK graph and clears every one ofEntity's dependents set-based, deepest-first, in one atomic transaction (RunFkGraphTeardown), on BOTH SQL Server and PostgreSQL (quoting + the FK-graph catalog query come from the provider'sSQLDialect). This covers dependents the entity-layer path under-deletes (base-view joins hide FK-enforced rows).Delete()inside ONE TransactionGroup, committed once (all-or-nothing, PG3). Under-deletes (misses dependents likeRecordChange), so it exists only for 2-arg callers that pass no provider; pass aDatabaseProviderto get the complete cascade.NOTE: the FK-graph path executes raw set-based SQL — it does NOT go through the
BaseEntitypipeline, so it emits no RecordChange audit rows, fires no*EntityServerdelete hooks, and (most importantly) fires no BaseEntity events, so provider/engine metadata caches are NOT invalidated. Fine formj app remove(the CLI process exits), but a caller invoking this inside a long-running process should refresh metadata afterward. See RunFkGraphTeardown.In BOTH paths the app-owned Application rows — the link-detected set unioned with the migration-declared set — are dropped after teardown (so a re-install's fixed-UUID
spCreateApplicationdoesn't PK-collide). Exported for unit testing of the atomic-transaction semantics (PG3).