Protected_The database-specific code generation provider, resolved from
MJGlobal.ClassFactory against the configured dbPlatform. Each provider
(SQLServerCodeGenProvider, PostgreSQLCodeGenProvider, …) registers
itself with @RegisterClass(CodeGenDatabaseProvider, '<platform>') —
the canonical DatabasePlatform value as its key — so this
single line picks up the right one without dialect-specific branching.
Subclasses can override via @RegisterClass(... priority) to plug in
customized codegen behavior, same hook every other MJ class uses.
Protected_ProtectedcascadeTracks cascade delete dependencies between entities. Key: Entity ID whose update/delete SP is called by other entities' delete SPs Value: Set of Entity IDs that have CascadeDeletes=true and call this entity's update/delete SP
Protecteddriftedschema.routine keys of CRUD routines whose live definition differed from the body generated
this run, so they were force-logged and re-executed. Reported once after generation.
ProtectedentitiesTracks entities that need their delete stored procedures regenerated due to cascade dependencies
ProtectedentitiesArray of entity names that qualify for forced regeneration based on the whereClause filter
ProtectedexistingMap of schema.routine (lowercased) to its live OBJECT_DEFINITION text on SQL Server,
used by isRoutineSaveReturnModeChanged to detect when Entity.Configuration.SaveReturnMode
changed via mj sync push without a physical table/column change, and by
isRoutineDefinitionDrifted to detect any other difference from the generated body.
Protectedexistingschema.routine keys (lowercased) present in the database at the start of
this SQL-generation pass. Used to force-log CREATE PROC for routines that
were dropped out-of-band (BigSchemaDemo recreate, a failed prior batch)
while the entity itself is not in newEntityList/modifiedEntityList.
ProtectedfilterFlag indicating whether to filter entities for forced regeneration based on entityWhereClause
ProtectedlayeredNames of LAYERED entities whose outer-view refresh was written right after their inner view (logLayeredOuterViewRefresh). STEP 2(f) does not log their refresh a second time.
ProtectedlayeredNames of LAYERED entities whose generated inner view was written to the migration log this run. Their application-owned outer view must be refreshed in the same migration, even when the entity is on neither the new nor the modified list (the inner view changed on its own).
ProtectedorderedOrdered list of entity IDs for delete SP regeneration (dependency order)
ProtectedanalyzeAnalyzes cascade delete dependencies without generating SQL. This method only tracks which entities depend on others for cascade operations.
ProtectedapplyApply reason-specific fixups after late-phase view regeneration. Each regen reason may require additional SQL to be executed and logged to the migration output file.
Use ApplyPermissions.
ProtectedbuildBuilds a complete map of cascade delete dependencies by analyzing all entities. This method populates the cascadeDeleteDependencies map without generating SQL.
ProtectedbuildBuilds a combined SQL string of sp_refreshview statements for the given entities.
For a LAYERED entity the outer refresh is guarded on the application-owned BaseView
existing, matching generateCustomBaseViewRefreshAndPermissions. On the first pass
after layering is enabled the outer view cannot exist yet — it selects from the inner view
that same pass creates — so an unguarded refresh here fails the documented setup procedure.
The inner view is refreshed first, before the outer. That ordering is defensive rather than
load-bearing: every entity reaching this method is in the modified/new list (see
getModifiedCustomBaseViewEntities), and logSQLForNewOrModifiedEntity forces a
modified entity's base view DDL into the same migration regardless of whether its text
changed — so the inner view is already dropped and recreated in an earlier step, which
resets its cached column list more thoroughly than a refresh would. The ordering is kept
anyway so this path cannot become wrong if that coupling is ever loosened.
ProtectedbuildProtectedbuildProtectedcheckFetches the current base view definition from SQL Server and compares it against newly generated SQL. If the view body has changed (e.g., a virtual field was added to a joined table), the entity is logged and executed. Unlike adding to modifiedEntityList (which would cause all SPs, permissions, indexes, etc. to be logged too), this only logs the base view SQL itself.
Comparison extracts the SELECT body from both the DB definition (CREATE VIEW ... AS
) and the generated SQL, normalizing whitespace for a fair comparison.true if the base view changed, false otherwise
ProtectedcheckPostgreSQL base-view change detection by COLUMN SET rather than text.
pg_get_viewdef() re-qualifies columns and normalizes whitespace/casing, so the SELECT-body text comparison used on SQL Server never byte-matches on PG and false-flags nearly every view. The base view exposes exactly the entity's fields, so comparing the view's live column set (information_schema.columns) against the entity's expected field set is deterministic, immune to that reformatting, and still catches the cases that matter:
NOT caught (by design — a tradeoff vs. SQL Server's text comparison): a view-BODY change that
leaves the exposed column NAMES identical — e.g. a RelatedEntityNameFieldMap re-pointed to a
different source column under the same output alias, or a codegen view-template change that
rewrites the SELECT without renaming columns. Those alter the SELECT text but not the column set,
so they must be forced through the metadata-driven modifiedEntityList (or an explicit
EntitiesRequiringViewRegen entry), not this column-set check.
true if the view's column set differs from the entity's fields (or the view is missing)
ProtectedCleanupFinds stale One To Many EntityRelationship rows among in-scope entities and, when the
cleanupStaleRelationships config option is set, deletes them; otherwise each one is logged as a
warning (#2071). Refreshes the global metadata only when rows were deleted, so the late-phase
regeneration that follows sees the current relationships.
false when the cleanup failed
ProtectedcreateProtectedcreateProtectedcreateProtecteddetectDetects self-referential foreign keys in an entity (e.g., ParentTaskID pointing back to Task table) Returns array of field info objects representing recursive relationships
A column that IS the entity's own primary key is excluded. It can carry a self-referencing
RelatedEntityID — FK auto-detection matches a <prefix>_key-style column to its own table
and does not exclude that table's own key — but "my parent is me" is not a hierarchy. The
generated recursive CTE then joins the key to itself and selects the same column three times,
which the database rejects outright: 15 entities on one Postgres instance failed to compile
with column reference "tea_key" is ambiguous. Nothing downstream can recover from that, and
a real hierarchy always parents on a DIFFERENT column, so excluding the key loses nothing.
ProtectedemitEmits sp_refreshview statements into the migration log file for modified custom base view entities (BaseViewGenerated === false). This ensures that when the migration runs on other environments, custom base views affected by schema changes get refreshed automatically. Only entities in the modified or new entity lists are included.
Generates the entity's per-phase SQL pieces (view, CRUD functions, view permissions) and dispatches them to the provider's phased executor. Lives here because it needs access to the internal generators; the provider doesn't own context building for the view.
ProtectedextractExtracts the SELECT body from a CREATE VIEW statement, normalizing whitespace for comparison. Handles both DB-stored definitions (CREATE VIEW ... AS SELECT ...) and generated SQL (which includes DROP VIEW, comment headers, GO, and permissions after the view body).
ProtectedforceWhether a CRUD routine's SQL must be logged and executed regardless of the new/modified lists.
generatedSQL, when given, is the body generated this run and enables the live-definition drift
check (isRoutineDefinitionDrifted).
OptionalgeneratedSQL: stringProtectedformatFormats a default value for use in SQL, handling special cases like SQL functions
The default value from the database metadata
Whether the field type typically needs quotes
Properly formatted default value for SQL
ProtectedgenerateGenerates all inline Table Value Functions for an entity's recursive foreign keys Returns empty string if no recursive FKs exist
ProtectedgenerateGenerates guarded permission statements for each registered alternate base view on entity:
Active / Deprecated) views receive GenerateViewPermissionsForTarget (REVOKE + GRANT SELECT + FLS DENY SELECT).Disabled views receive GenerateDisabledViewRevokePermissionsForTarget (REVOKE SELECT) so disabling a view revokes database read grants.OptionalbatchSize?: numberOptionalenableSQLLoggingForNewOrModifiedEntities?: booleanOptionalwillRegenerate?: Set<string>Optional UNION of will-regenerate keys across ALL batches in the same codegen run. When provided, takes precedence over the per-batch set.
This function will handle the process of creating all of the generated objects like base view, stored procedures, etc. for all entities in the entities array. It will generate the SQL for each entity and then execute it.
OptionalbatchSize?: numberOptionalenableSQLLoggingForNewOrModifiedEntities?: booleanOptionalprogressLabel?: stringPhase name for the per-batch progress line, e.g. 'Generating SQL'. Defaults from
onlyPermissions. See reportEntityBatchProgress for why the line exists.
OptionalwillRegenerate?: Set<string>Optional UNION of will-regenerate keys across ALL batches in the same codegen run. When provided, takes precedence over the per-batch set.
OptionalenableSQLLoggingForNewOrModifiedEntities?: booleanOptionalwillRegenerate?: Set<string>Names of other entities regenerating in this run — passed to the PG phased executor's willRegenerate so stale captured dependents that will be rebuilt anyway aren't restored.
OptionalenableSQLLoggingForNewOrModifiedEntities?: booleanOptionalwillRegenerate?: Set<string>Names of other entities regenerating in this run — passed to the PG phased executor's willRegenerate so stale captured dependents that will be rebuilt anyway aren't restored.
Use GenerateBaseView.
ProtectedgenerateSame as generateBaseView, but returns the view DDL and the GRANT/permissions
DDL as separate strings rather than concatenating. Used by phased per-entity
execution paths (e.g. PG's phased executor) where the view must run under
42P16 fallback recovery but the permissions must run afterwards in a later
phase — concatenating them would prevent the executor from detecting where
a failure actually occurred.
ProtectedgenerateProtectedgenerateProtectedgenerateEmits the refresh + permission statements for an entity whose BaseView CodeGen does NOT
write — fully custom, or the application-owned outer half of a layered entity.
The refresh runs before the grants so SQL Server picks up schema changes (new columns from migrations) before permissions are applied; developers no longer add it by hand.
Two things are specific to LAYERED entities:
g.* from the generated one, and a view
caches its column list. Refreshing the outer against a stale inner re-caches the OLD
columns, so a newly added column stays missing — indistinguishable from never having been
added at all, which is the exact failure layering exists to eliminate.GRANT both fail — and the step they fail on is the documented setup procedure, so
there would be no way to adopt the feature at all. Guarding makes the bootstrap pass skip
them and leaves every later pass identical to the unguarded form.ProtectedgenerateProtectedgenerateProtectedgenerateBubble lat/lng from EmbeddedRecord peers as __mj_Latitude_{FK}.
Geocode lives on the Address (or other source); the parent only displays it.
ProtectedgenerateProtectedgenerateGenerates the SELECT clause additions for hierarchy metadata fields from TVFs
Projects: Root
ProtectedgenerateGenerates JOIN clauses to inline Table Value Functions for hierarchy metadata calculation
Generates the SQL for creating indexes for the foreign keys in the entity. Delegates to the database provider for platform-specific index DDL.
Generates the composite index covering the entity's SOFT primary key. Empty for every
entity with a real PRIMARY KEY constraint, which is nearly all of them.
Kept separate from generateIndexesForForeignKeys and gated by its own setting: a soft-PK index serves MJ's own per-record existence check on the create path, which is a different concern from indexing foreign keys for joins and filters, and an operator's opinion about one is not an opinion about the other.
ProtectedgenerateGenerate SELECT aliases for native lat/lng fields → __mj_Latitude / __mj_Longitude. Virtual fields are excluded — see hasNativeGeoFields for the rationale.
ProtectedgenerateGenerates SELECT field expressions for IS-A parent entity columns. Walks the ParentID chain upward, joining to each parent's base table, and includes the columns physically on each parent table (InheritedParentColumns). Returns a string starting with ',\n' if there are parent fields, or '' if none.
ProtectedgenerateGenerates INNER JOIN clauses for IS-A parent entity base tables. Chains joins from child -> parent -> grandparent using PK-to-PK conditions. Each parent is joined via its base table (not view) to avoid view dependency ordering issues.
ProtectedgenerateGenerate SELECT aliases from the RecordGeoCode LEFT JOIN → __mj_Latitude / __mj_Longitude.
ProtectedgenerateProtectedgenerateGenerates the SELECT clause additions for root and hierarchy fields from TVFs
ProtectedgenerateGenerates an inline Table Value Function for calculating root ID for a recursive FK field The function takes both the record ID and parent ID for optimization Returns SQL to create the function including DROP IF EXISTS
ProtectedgenerateGenerates joins to inline Table Value Functions for hierarchy and root ID calculation
ProtectedgenerateProtectedgenerateProtectedgenerateProtectedgenerateProtectedgenerateProtectedgenerateProtectedgenerateProtectedgetBuilds guarded refresh/rebind statements for each registered alternate base view on entity
(including Disabled views so Active children of a Disabled parent and re-enabled views
never hold stale column metadata) in topological ParentID order.
ProtectedgetIncluded entities whose base view is application-owned (fully custom or layered), that have a base view, are not virtual or externally sourced, and are in the custom-view refresh scope.
ProtectedgetIdentifies entities that need their delete stored procedures regenerated due to cascade dependencies on entities that had schema changes.
ProtectedgetHelper to get the canonical hierarchy function definitions and metadata for an entity and recursive FK field.
ProtectedgetProtectedgetReturns entities from the modified and new entity lists that have custom base views (BaseViewGenerated === false), are included in the API, and are not virtual.
ProtectedgetGets entities that had schema changes from the ManageMetadataBase tracking. Returns a map of entity names to their IDs for entities that had update-affecting changes.
ProtectedgetReturns all registered alternate base views with valid SQL identifiers for entity
(including Status === 'Disabled'), ordered topologically by ParentID.
ProtectedgetReturns usable (Status !== 'Disabled') alternate base views for entity,
ordered topologically by ParentID so parent views precede derived child views.
ProtectedhasProtectedhasCheck if an entity has native latitude/longitude fields marked with GeoLatitude/GeoLongitude ExtendedType. If both exist, the view should alias them directly instead of joining to RecordGeoCode.
MUST exclude virtual fields. The view-introspection pass creates virtual
EntityField rows for the __mj_Latitude/__mj_Longitude SELECT aliases
the JOIN path emits, then auto-assigns ExtendedType=GeoLatitude/Longitude
by name-pattern. Without this filter the next view regen flips to the
native path and tries to SELECT e.__mj_Longitude from the base table —
the column doesn't exist on the table, only on the view itself, so view
creation fails with "Invalid column name '__mj_Longitude'". This recurs
on any geo-eligible entity whose RecordGeoCode-based view ran once.
ProtectedhasValidates that an alternate base view's EffectiveSchemaName and ViewName
(and its ParentView's when present) are valid SQL identifiers before splicing
into generated DDL or catalog queries.
ProtectedisChecks if a field is part of a composite (multi-column) unique constraint. Returns true if the field participates in a unique index with 2+ columns. This is used to determine if a nullable FK should use DELETE instead of UPDATE during cascade operations, since setting to NULL could violate uniqueness.
ProtectedisReturns true when the live definition of the entity's spCreate / spUpdate / spDelete differs
from generatedSQL, the body CodeGen generated for it this run, after both are normalized by
the provider (comments, header, DROP batch, GO and whitespace removed).
This catches drift that never reaches the new/modified entity lists: a column default or type
synced by R__RefreshMetadata before CodeGen ran (#5636), or a cascade target whose column a
migration dropped together with its EntityField row (#3343). Returns false when the live
definitions were not loaded (PostgreSQL, or the catalog query failed), when the routine is
missing (handled by isRoutineMissing), or when either side cannot be normalized.
ProtectedisProtectedisReturns true when spCreate or spUpdate in the database was generated under a different
SaveReturnMode ('full' vs 'datestamps_only') than the entity's current metadata.
This ensures that when Entity.Configuration.SaveReturnMode is updated via mj sync push,
the subsequent mj codegen run automatically logs and executes the updated stored procedures.
ProtectedloadSnapshot every CRUD routine currently in the database (one query) so
generate-and-log can force-emit CREATE PROC for objects that vanished
without the entity landing on newEntityList/modifiedEntityList, or whose
return-row mode (SaveReturnMode) changed via mj sync push.
ProtectedlogWrites the layered entity's view refresh (buildCustomBaseViewRefreshSQL: inner view,
then the guarded outer view, its rebind and alternate views) into the migration log AND the
temp batch STEP 2(e) executes, right after the inner view and before the entity's CRUD routines
(#4927). The application-owned outer view selects g.*, and SQL Server freezes that column list
when the view is created; when the inner view's columns change, the routines that read the
outer view fail to compile until it is refreshed. STEP 2(f) refreshes the outer view too, but
only after the batch has run, which is too late for the routines in it.
Called only when the inner view was logged, whether or not the entity is on the new/modified lists. No-op on platforms that rebind views themselves (PostgreSQL's phased executor).
ProtectedlogWrites generated SQL to the migration log (and the temp batch executed on SQL Server) when the
entity is new/modified, a force-regeneration rule matches, or forceLog is set. Returns whether
the SQL was logged.
ProtectedmarkMarks entities for delete stored procedure regeneration based on cascade dependencies. This should be called after metadata management and before SQL generation.
ProtectedorderOrders entities by their cascade delete dependencies using topological sort. Ensures that if Entity A's delete SP calls Entity B's update/delete SP, then Entity B is regenerated before Entity A.
All entities for name lookup
Set of entity IDs that need ordering
Array of entity IDs in dependency order
ProtectedprepareBuilds the once-per-run FieldSecurityRunContext and hands it to the dialect provider (whose permission emitters are synchronous string builders and cannot query). Three inputs, all read here:
MJ: Roles metadata rows with a non-blank SQLName, EXCLUDING
the standard UI/Developer/Integration roles: by decision D1a, field-security DENYs
target custom (DBA-created) roles only, so standard roles never enter
RoleSQLNameByID and Deny rows against them stay app-tier-enforced.sys.database_role_members). Protected principals default to the known service
logins (MJ_Connect, MJ_Connect_Dev) plus the configured CodeGen login; a DENY
to such a role would strip the column from the service login itself.sys.database_permissions entry (object- and
column-level) granted to a managed role, keyed by <schema>.<object>. This powers
the wipe-and-reassert reconciliation (decision D7) that finally makes permission
REMOVAL propagate: the historical model was assert-only, so a deleted
EntityPermission / Deny row left its GRANT/DENY in the database until the view
happened to be regenerated.SQL Server only (PostgreSQL emits no DB-tier field security, decision D2). Any failure degrades to a null context — emitters fall back to the historical grants-only output — with a prominent warning, never a failed run.
Executes the custom base view refresh (buildCustomBaseViewRefreshSQL: inner view, then the guarded outer view, then its rebind and alternate views) against the live database for EVERY included entity whose base view is application-owned, and writes the refresh for the entities whose views changed this run into the migration log.
Runs right after STEP 2(e), so the outer views expose the columns the regenerated inner views
now have before STEP 3 compares EntityField rows against them (#4336). Every entity is
attempted; failures are logged together and make the step return false.
Only the entities on the new/modified lists, plus layered entities whose inner view was logged this run, go into the migration log. Logging every custom view on every run would make a capture non-empty when nothing changed.
ProtectedreportLogs the CRUD routines that were regenerated because their live definition had drifted.
ProtectedreportEmits the one live progress line for the entity generation/permissions loop: which phase, how far through, which entity is being worked on, and how long the phase has been running.
WHY. The spinner already re-renders an elapsed timer every 100 ms, so a long run is not silent
— but the message it re-renders was set ONCE before the loop ("Generating SQL for 1,200
entities…") and never changed again. A run that has been sitting on entity 3 for four minutes
and a run that is on entity 1,180 render identically, which makes a stall and normal progress
indistinguishable. N/total is the whole difference.
Called per BATCH rather than per entity: the batch is the unit of concurrency (its members run
under one Promise.all), so a per-entity line would just interleave five entities' names at
random. The named entity is the batch's first, which is what the run is demonstrably on.
UpdateSpinner covers both output modes by construction — in verbose mode it routes to
logStatus, so a verbose run gets the same information as a line per batch instead of a
re-rendered spinner.
Use RunCustomSQLScripts.
ProtectedshouldTrue when this run's migration log must carry the entity's custom base view refresh.
ProtectedstripProtectedvalidateAudits each usable alternate base view on entity for column parity with BaseView,
catalog dependency on BaseView / ParentView (D10), and CachePolicy = 'Default'
safety (clock functions or external relation dependencies). Logs warnings via LogWarning.
ProtectedvalidateProtectedvalidateWarns about IS-A children outside this run's scope whose live view lacks a column their in-scope parent's table now has (#4821). This run cannot regenerate those views: the child belongs to another app, which must run CodeGen or ship a migration. Until it does, the child's metadata (synced by that app's run) and its view disagree, and its saves fail. Never fails the run; a failed catalog read is logged and ignored.
ProtectedwriteWrites a generated SQL file to disk only if the content has changed from the existing file. Returns true if the file was written (content changed or file is new), false if unchanged. This avoids false timestamp updates and unnecessary I/O.
This class is responsible for generating database level objects like views, stored procedures, permissions, etc. You can sub-class this class to create your own SQL generation logic or implement support for other databases. The base class implements support for SQL Server. In future versions of MJ, we will break out an abstract base class that has the skeleton of the logic and then the SQL Server version will be a sub-class of that abstract base class and other databases will be sub-classes of the abstract base class as well.