Available Tables

The catalog provides several tables that can be queried using standard SQL syntax. Use LIST CATALOG TABLES to list all available tables in your catalog.

Discovering Tables

LIST CATALOG TABLES;

Core Tables

CATALOG.ENTITIES

Information about all entities in the project.

SELECT Name, EntityType, AttributeCount
FROM CATALOG.ENTITIES
WHERE ModuleName = 'Sales'
ORDER BY Name;

CATALOG.ATTRIBUTES

Information about entity attributes.

SELECT a.Name, a.AttributeType
FROM CATALOG.ATTRIBUTES a
JOIN CATALOG.ENTITIES e ON a.EntityId = e.Id
WHERE e.QualifiedName = 'Sales.Customer';

CATALOG.MODULES

One row per module, including System and Marketplace modules.

SELECT Name FROM CATALOG.MODULES
WHERE Source = '' AND COALESCE(DomainModelDocumentation, '') = '';

CATALOG.ASSOCIATIONS

Information about entity associations, same-module and cross-module.

Mendix’s Parent/Child pointer names are inverted relative to MDL’s FROM/TO: ParentPointer is the FROM entity and ChildPointer the TO entity, so the Child* delete behaviour belongs to the TO end. Mendix always stores both ends, so an explicitly set behaviour is one that is not the default. System module associations have no stored delete behaviour and read as ''.

SELECT QualifiedName, ToDeleteBehavior, FromDeleteBehavior
FROM CATALOG.ASSOCIATIONS
WHERE ToDeleteBehavior <> 'DeleteMeButKeepReferences'
   OR FromDeleteBehavior <> 'DeleteMeButKeepReferences';

CATALOG.MICROFLOWS

Information about microflows, nanoflows and rules (CATALOG.NANOFLOWS is the nanoflow subset).

SELECT Name, ReturnType, ActivityCount, TotalActivityCount
FROM CATALOG.MICROFLOWS
WHERE ModuleName = 'Sales'
ORDER BY Name;

CATALOG.ACTIVITIES

One row per object in a microflow, nanoflow or rule body — activities, splits, merges, events, loops and annotations. Populated by REFRESH CATALOG FULL.

Loop bodies are included. The objects inside a loop, at any depth, are rows too, with ParentLoopId naming the loop. Earlier releases left them out; a query written then that should keep its old result filters on ParentLoopId = ''.

-- Database retrieves inside a loop (N+1 queries)
SELECT MicroflowQualifiedName, EntityRef, LoopDepth
FROM CATALOG.ACTIVITIES
WHERE ActionType = 'RetrieveAction' AND RetrieveSource = 'database' AND ParentLoopId <> '';

-- Microflows called from inside a loop, synchronously (a queued call runs outside it)
SELECT MicroflowQualifiedName, ActionRef
FROM CATALOG.ACTIVITIES
WHERE ActionType = 'MicroflowCallAction' AND ParentLoopId <> '' AND QueueRef = '';

CATALOG.PAGES

Information about pages and their properties.

SELECT Name, Title, URL
FROM CATALOG.PAGES
WHERE ModuleName = 'Sales'
ORDER BY Name;

Page templates are not pages and are not in this table — see CATALOG.PAGE_TEMPLATES.

CATALOG.WIDGETS

One row per widget instance on a page or snippet. Full build only (refresh catalog full); a fast build leaves the table empty.

-- Widgets nested more than five deep, deepest first
SELECT ContainerQualifiedName, Name, WidgetType, Depth
FROM CATALOG.WIDGETS
WHERE Depth > 5
ORDER BY Depth DESC;

-- Buttons that delete without going through a flow
SELECT ContainerQualifiedName, Name
FROM CATALOG.WIDGETS
WHERE ActionType = 'Forms$DeleteClientAction';

CATALOG.PAGE_TEMPLATES

The starting points Studio Pro’s “new page” dialog offers (Forms$PageTemplate). A separate document type from pages: Atlas_Web_Content ships 46 templates and no pages at all.

There is no DESCRIBE PAGE TEMPLATE, so a template is indexed but not describable — tools that walk a module report it as unknown, never as unchanged.

CATALOG.LAYOUTS

Page layouts (Forms$Layout), including those in Marketplace modules such as Atlas_Core.

-- pages on a native layout (needs a full build for LayoutRef)
SELECT p.QualifiedName
FROM CATALOG.PAGES p JOIN CATALOG.LAYOUTS l ON l.QualifiedName = p.LayoutRef
WHERE l.Platform = 'Native';

CATALOG.ACCESS_RULES

Information about entity access rules (available after full refresh).

SELECT e.QualifiedName, ar.UserRole, ar.AllowRead, ar.AllowWrite
FROM CATALOG.ACCESS_RULES ar
JOIN CATALOG.ENTITIES e ON ar.EntityId = e.Id
WHERE e.ModuleName = 'Sales';

CATALOG.SCHEDULED_EVENTS

Scheduled events — Mendix’s cron.

IntervalSeconds comes from the schedule, not from the stored Interval/IntervalType pair. Those are a legacy sibling that Studio Pro writes and does not keep in sync — a shipped Mendix module stores 0/Minute beside a daily schedule — so a query keyed on them would read a nightly job as firing every 0 seconds. Month and year figures are averages (30 and 365 days): the column is for thresholds and ordering, not calendar arithmetic.

-- Anything that fires more often than once a minute
select QualifiedName, RepeatDescription, Microflow
from CATALOG.SCHEDULED_EVENTS
where Enabled = 1 and IntervalSeconds < 60;

-- Scheduled events whose microflow no longer exists
select se.QualifiedName, se.Microflow
from CATALOG.SCHEDULED_EVENTS se
left join CATALOG.MICROFLOWS m on m.QualifiedName = se.Microflow
where m.Id is null;

A scheduled event also produces a schedule row in CATALOG.REFS, so list callers of <microflow> and the dead-asset analysis both see it. Without that edge a microflow run only by a scheduled event looked unreferenced.

CATALOG.QUEUES

Task queues.

Parallelism is stored as text because Mendix stores an expression: a query must not assume it parses as an integer.

select QualifiedName, Parallelism, ClusterWide from CATALOG.QUEUES;

Offline synchronization

CATALOG.OFFLINE_ENTITY_CONFIGS — one row per entity an offline navigation profile synchronizes.

select ProfileName, EntityQualifiedName, SyncMode, XPathConstraint
  from CATALOG.OFFLINE_ENTITY_CONFIGS
 where SyncMode = 'All';

CATALOG.NAVIGATION_PROFILES.OfflineEntityCount says how many and nothing else; this table is what makes “which entities does this profile sync, and how?” answerable — the first question anyone auditing an offline app asks.

SyncMode is the value Mendix stores, not the caption Studio Pro shows: All, Constrained, Never, None, NoneAndPreserveData, Online. Its dialog’s “All Objects” is All and “By XPath” is Constrained.

CompatibilityMode is indexed although MDL cannot author it. The catalog reports what is stored, and a flag invisible to every query is one nobody discovers until it matters.

A configured entity also produces a sync row in CATALOG.REFS, so list references to Sales.Order names the profiles that download it:

select SourceName, TargetName from CATALOG.REFS where RefKind = 'sync';

Every mode gets an edge, including the ones that download nothing. A profile with sync Sales.Audit never still names that entity, so renaming or dropping it leaves the configuration dangling — which is precisely what a reference edge exists to reveal.

Entity event handlers

CATALOG.ENTITY_EVENT_HANDLERS — one row per entity event handler: which moment, which event, and which microflow runs.

select EntityQualifiedName, Moment, Event, Microflow
  from CATALOG.ENTITY_EVENT_HANDLERS
 where Moment = 'Before' and Event = 'Commit';

CATALOG.ENTITIES.HasEventHandlers says some exist and nothing else — the same shape NavigationProfile.OfflineEntityCount had. The distinction the flag loses is the one that matters: a Before handler with RaiseErrorOnFalse can veto the commit, an After handler cannot.

Moment is Before or After. Event is the value Mendix stores, not the caption Studio Pro shows: Create, Commit, Delete, RollBack — note the capital B, which generated/metamodel confirms (DomainModelsEventRollBack = "RollBack") and which disagrees with every neighbouring enum in that file, where the same word is Rollback. A query spelling it the expected way returns zero rows rather than an error.

A handler also produces an event row in CATALOG.REFS, so a microflow that runs only as a handler has callers:

select SourceName, TargetName from CATALOG.REFS where RefKind = 'event';

Without that edge the handler microflow was reported dead from three directions at once — list callers said (no callers found), CATALOG.GRAPH_DEAD_ASSETS listed it, and mxcli lint emitted QUAL004 “is not called from anywhere” with the suggestion Remove if unused — on code that runs on every commit (mendixlabs/mxcli#1127).

The edge carries neither the moment nor the event; refs has no column for them, and a kind per combination would put eight kinds into every consumer’s list to say one thing. Which moment and which event is this table’s question.

Graph-Analysis Tables

The dependency graph (CATALOG.REFS, full refresh) is analysed by a family of graph_* views and tables — god nodes, module coupling/cohesion, dead documents, communities, cycles, layers, centrality, and the integration surface. The community/cycle/layer/centrality tables are populated by REFRESH CATALOG COMMUNITIES — a pass, not a build mode, so a full-mode catalog has them empty until it runs and a query against one says so rather than returning 0 rows. See Graph Analysis for the full reference and the mxcli graph-report command.

Cycles come in two flavours, because they are two questions: CATALOG.GRAPH_CYCLES for tangled documents and CATALOG.GRAPH_MODULE_CYCLES for tangled modules — the second is not a rollup of the first, since modules reference each other through documents that need form no cycle themselves. CATALOG.GRAPH_ANALYSIS_SCOPE reports which reference kinds reach the computed asset graph, which is what to check when a graph_module_coupling edge seems to have no effect on cycles or layers.

select * from CATALOG.graph_god_nodes order by Degree desc limit 20;
select * from CATALOG.graph_module_coupling order by Edges desc;
select * from CATALOG.graph_module_cycles order by CycleSize desc;
list communities;

Listing All Tables

To see the complete list of available tables in your catalog (which may vary by project and refresh level):

LIST CATALOG TABLES;

mxcli -p app.mpr -c "LIST CATALOG TABLES"