If it references something, copy that too

The "References" badges in the entity tree are not decoration. They predict whether your inserts will land or fail at the target.

3 min read

When you pick entities for a Copy action, DMM Infinity shows two indicators next to each entity name: References (entities this one depends on) and Referenced by (entities that depend on this one). Mendix enforces foreign-key integrity on writes; a Copy that ignores the dependency graph either errors out at insert time or, worse, half-succeeds and leaves you with orphaned rows.

The pitfall in one line
Pick Employee but not Department, and the first batch of Employee inserts hits the target with a foreign key that has nowhere to point.

Why this happens

DMM Infinity copies entity-by-entity in dependency order. If a referenced entity is missing from the selection, the agent on the target side throws on the constraint as soon as the first dependent row tries to land. Some failures are loud (the run stops with a clear error). Some are quiet — entities with nullable references will skip the row silently and continue, leaving you with the appearance of a successful copy and a target that is missing data.

The rule of thumb in the UI

For every entity you select, also select everything it References. The reverse — every Referenced-by entity — is optional unless you want their rows in the target as well. The UI gives you a per-entity Select-all on each References / Referenced-by section so you can grab a closure of the graph in one click.

Do
  • ·Use the per-entity "Select all" under References to pull in every parent entity in one click.
  • ·Select entire modules at the module level when the cross-module references are not the ones you care about.
  • ·Re-check the count at the top of the Select Entities step after each addition — it tells you what the run will actually move.
  • ·Think about cardinality: if you skip a Referenced-by entity, those rows just will not exist on the target.
Don't
  • ·Cherry-pick a single entity and assume its references will tag along. They will not.
  • ·Trust a successful run as proof of completeness — count rows on the target side too.
  • ·Confuse References with Referenced-by. The UI labels are precise; reading them backwards costs runs.

A concrete example

An HR migration in the demo environment selected six entities from the HR Management module: Address, Department, Employee, Leave Request, Performance Review, and Project. Department was deselected because "we already have departments in the target". Of the 1,400 Employee rows the source held, 1,200 had a non-nullable Department reference; those failed at insert. Adding Department back to the selection — one click — turned the next run into a clean 1,400 / 1,400.

Rule of thumb
For every entity you select, also select everything it References. When in doubt, copy by module — the module-level Select-all gives you a valid sub-graph for free.
Still need help?
If this article does not solve it, the DMM Infinity team is one ticket away.
Submit a ticket