Mendix Expert Developer cheat sheet

Persistent entity = database table; non-persistent entity = in-memory object only, never stored, no System attributes (no ID, CreatedDate, ChangedDate).

System attributes on persistent entities: ID (AutoNumber/Long), ChangedDate, CreatedDate, Owner, ChangedBy - Owner/ChangedBy only populated when the entity is a subclass of System.User or System.FileDocument or when the association to the user is set.

Inheritance: a specialization shares the ID space with its generalization (one table, single-table inheritance). A persistent specialization of a persistent entity adds columns to the same table; a non-persistent specialization of a persistent entity is allowed and stores nothing.

Associations: reference (1-1, 1-*) stores a foreign key on the child side; many-to-many is stored in a separate join table. Association storage: 'Store owner' vs 'store both' - both directions costs an extra index/column and is only needed for reverse navigation performance.

Delete behavior: 'Delete 'Entity'' cascades deletes to the associated object; 'Delete 'Entity' and references' removes references; 'Prevent delete' raises an error. Default is 'Prevent' when the association is not part of a delete rule.

Calculated attributes (virtual, non-persistent) are computed by a microflow or by an attribute expression and are never stored; use them for derived values instead of duplicating data.

Denormalize only for measured read hot paths; a duplicated column must be maintained by a microflow or event handler (before/after commit) or it will drift.

Entity naming: use singular nouns, PascalCase, no prefixes; module prefix is added automatically in the database table name (ModuleName$EntityName).

Microflow vs nanoflow: a microflow runs server-side in a transaction; a nanoflow runs client-side in the browser, cannot use Java actions, database, or non-persistent objects retrieved from the server unless passed as a parameter.

Microflow settings: 'Synchronize' (default) commits at the end of the microflow; 'Async' returns immediately and commits; 'Never' rolls back on error. Error handling: 'Rollback' (default) vs 'Custom with error handler'.

Loop with 'Create variable' inside: the variable is re-created each iteration; a 'Change variable' outside the loop accumulates. Use 'Aggregate list' (count, sum, average, min, max) instead of a manual loop.

Retrieve with 'Retrieve' activity: range 'First'/'All', XPath constraint, sorting; 'Retrieve by association' is faster than an XPath join for 1-* navigation.

Split/merge: 'Split' creates parallel paths; each path runs sequentially in the same transaction (not parallel threads). Use 'Parallel' only via async microflow calls.

Commit, rollback, and delete: 'Commit' persists, 'Rollback' undoes uncommitted changes in the current transaction; 'Delete object' marks for deletion, persisted on commit.

Java action parameters: pass primitives and entities; return values cannot be a list of non-persistent objects unless the action is configured to allow it. Use 'Call REST' or 'Call web service' activities before writing custom Java.

Error handling: 'Error event' + 'Continue' + 'Rollback' inside a loop lets you skip failing items; a microflow returning a Boolean is the standard 'validation' sub-microflow pattern.

Module roles vs user roles: module roles are defined per module and grant entity/microflow/page access; user roles are app-level and map to one or more module roles. A user gets the union of all module roles of all assigned user roles.

Entity access rules: each rule has a module role, create/read/write/delete flags, an XPath constraint, and member-level access (which attributes are readable/writable). Rules are OR-ed for a user; the most permissive matching rule wins per attribute.

XPath constraints on entity access are evaluated against the current user via tokens like [%CurrentUser%]; a rule without a constraint grants access to all objects of that entity.

Microflow access: 'Allowed roles' on the microflow; a microflow with no allowed roles can only be called from other microflows, not from the client.

Page access: allowed module roles per page; a page with no roles is unreachable from the navigation. Navigation items are filtered by role.

Demo users are configured in Project Security and only exist in the development environment; production users come from the configured authentication (MxAdmin, LDAP, SSO, or custom).

Password policy, session timeout, and 'Enable demo users' are project-level settings; 'Strict mode' blocks access to pages/microflows not explicitly allowed.

System.User, System.UserRole, and System.FileDocument are the standard security entities; the Owner/ChangedBy system attributes are only filled when the entity is a specialization of System.User or System.FileDocument.

Consumed REST: 'Call REST (GET/POST/PUT/DELETE)' activity with URL, headers, body, and response handling; map JSON with an Import Mapping (JSON structure) or a 'JSON to object' via a non-persistent entity.

Published REST: define a resource on an entity or microflow, set the HTTP method, path, and operation; a microflow-based operation receives path/query/body parameters as primitives or an entity.

Published REST authentication: 'Custom' (microflow-based, e.g., API key check) or 'Basic' (username/password); the microflow must return a System.User or null.

Consumed SOAP: import a WSDL to generate a service definition; map the request/response with XML mappings; call with the 'Call web service' activity.

Published SOAP: 'Published web service' exposes a microflow as an operation with a message definition; document/literal wrapped is the default style.

Import/Export mappings: element-to-attribute mapping, 'By name' vs 'By path'; use 'Inheritance' for polymorphic JSON/XML; unknown elements are ignored unless 'Validation' is on.

Error handling: set 'HTTP response' status codes explicitly (400/401/404/500); an unhandled microflow error in a published REST operation returns HTTP 500 with the error message.

Timeouts and retries: the 'Call REST' activity has a timeout setting; retries must be implemented in the microflow (loop with a counter), not configured declaratively.

XPath vs SQL: XPath is translated to SQL; a constraint on an unindexed attribute causes a full table scan. Add an index on attributes used in frequent retrieve constraints and on association foreign keys.

Avoid N+1: retrieving a list and then retrieving an associated object per item in a loop is N+1 queries. Use 'Retrieve by association' with the list, or an XPath join, or a single retrieve with an 'in' constraint.

'Retrieve All' on a large table loads everything into memory; use paging (offset/limit) or an aggregate. The 'Count' aggregate is cheaper than retrieving the list.

Microflow memory: lists of persistent objects are held in the runtime's object cache; very large lists cause memory pressure. Use 'Retrieve' with a range and process in batches.

Commit behavior: committing inside a loop causes one transaction per iteration; commit once after the loop. 'Async' microflows free the client but still consume a runtime thread.

Client performance: a page with many data grids and nested list views issues many requests; use microflow data sources with paging, and avoid 'Retrieve All' data sources on large entities.

Scaling: the Mendix runtime is stateless with a shared database and file storage; horizontal scaling requires a shared database, shared file storage (S3/DB), and sticky sessions or a load balancer with session affinity.

Scheduled events run on one runtime instance (leader) in a multi-instance cluster; long-running scheduled events can delay other scheduled events on the same node.

Environment tiers: Development (MxAdmin, demo users, no license), Acceptance/Test, Production. Each environment has its own database and file storage; a deployment package is environment-agnostic.

Deployment package: built from a committed revision, contains the model, custom Java, and runtime; it is immutable. Constants are environment-specific and set per environment, not in the package.

Mendix Cloud: licensed nodes have a database, file storage, and a runtime; 'Transport' moves a deployment package between environments; 'Backup' retains a daily backup with a configurable retention.

Log levels: TRACE, DEBUG, INFO, WARNING, ERROR, CRITICAL. Set per log node in the environment; 'TRACE' is very verbose and should not be left on in production.

Custom settings: JVM heap (Xmx), database connection pool, and 'Application root URL' are per-environment. Heap should be sized relative to the container memory, leaving headroom for the OS and metaspace.

Stopping/starting: a stopped environment keeps its database and file storage; a 'Clean deploy' wipes the database and file storage and should only be used when data loss is acceptable.

MxAdmin is the built-in administrator account; in Mendix Cloud it is managed via the portal. The 'Admin' password should be rotated and not shared.

Health checks: the runtime exposes a health endpoint; the cloud platform restarts an instance that fails the check. Check 'Alerts' in the portal for CPU, memory, and disk thresholds.

Module boundaries: a module owns its entities and exposes microflows as its API; another module should call those microflows rather than directly manipulating the entities.

App Store modules: reusable modules with a version; upgrading replaces the module content and can overwrite local changes. Keep local changes in a separate module or use 'Replace' carefully.

Layered architecture: presentation (pages/nanoflows) → application (microflows) → domain (entities) → integration (REST/SOAP). Cross-layer calls go downward only.

Reusable microflow: parameterized, no UI dependency, returns a value or an object; place shared logic in a 'Common' or 'Logic' module.

Constants for configuration: environment-specific values (URLs, keys) belong in constants, not hard-coded in microflows; constants are overridden per environment.

Module roles enable reuse: a reusable module defines its own module roles, and the consuming app maps user roles to them; do not rely on app-specific user roles inside a reusable module.

Event handlers (before/after commit/create/delete) belong in the module that owns the entity; cross-module side effects should be triggered by a published event or a microflow call, not by a handler in another module.

Unit testing: Mendix Unit Testing module (MTA) writes microflow-based tests with 'Assert' activities; tests run in a test environment and report pass/fail per test case.

Test entities: create non-persistent test entities and test microflows in a separate 'Test' module; do not ship test microflows to production (use 'Allowed roles' and exclude from navigation).

Common runtime errors: 'An error occurred while retrieving...' usually means an XPath references a deleted attribute or a missing association; 'Object has been deleted' means a stale object reference.

Debugging: set breakpoints in the modeler (Studio Pro) against a running environment; the debugger pauses the runtime, so do not debug in production under load.

Log nodes: use 'Log message' with a named log node; the log level is set per node in the environment, so a DEBUG message is invisible unless the node is set to DEBUG.

Performance troubleshooting: enable 'TRACE' on the 'Query' log node to see generated SQL, and on 'Performance' to see slow microflows/pages.

Consistency errors: 'Check model' (F4) reports errors and warnings; a deployment is blocked by errors, warnings are advisory. Resolve before committing.

Team Server: Git-based (or SVN in older versions) repository hosted by Mendix; the local working copy is a .mpr file plus a model directory. Commit frequently; the model is a binary/JSON store, so merge conflicts are resolved in Studio Pro.

Branching: 'Main line' is the default branch; 'Create branch' from a revision; merging is done in Studio Pro with a conflict resolution dialog for changed documents.

Deployment pipeline: commit → build deployment package (in Studio Pro or the portal) → transport to acceptance → test → transport to production. The package is built once and promoted, not rebuilt per environment.

CI/CD: the Mendix 'Build' API and the Deploy API allow automated package creation and deployment; the Deploy API requires an API key per environment.

Version numbering: the app version (major.minor.patch) is set in Project Settings and shown in the portal; it does not automatically increment on deploy.

Database synchronization: a deployment runs 'Synchronize' which applies model changes (new columns, tables) to the database; destructive changes (dropping a column) require a manual migration or are blocked.

Rollback: redeploy a previous deployment package; the database is not rolled back automatically, so a schema-incompatible rollback can fail.