Modify¶

Commands that change the model. They share the mutation lifecycle described in Editing & staging: preview by default, persist with --save, batch with --stage, or write elsewhere with --save-to <path> (which implies --save). --serialization tmdl|bim controls the on-disk format, --force saves past validation errors, and --no-sync skips the workspace mirror.

Those shared lifecycle options are not repeated in the tables below.

add — add an object¶

tx add <path> [model] [options]

The path names the new object (Sales/Revenue, 'Sales'[Revenue]); relationships use Sales[Key]->Product[Key] (many side → one side).

tx add "Sales/Revenue" -t Measure -i "CALCULATE(SUM(Sales[Amount]))" --save
tx add tables/Sales/measures/Revenue -i - < expression.dax
tx add "Sales/Revenue" -i "SUM(Sales[Amt])" -q formatString -i "$#,0"

set — set a property¶

tx set <path> [model] [options]

tx set "Sales[Total Sales]" -q "CALCULATE(SUM(Sales[Amount]))"    # expression is the default property
tx set tables/Sales/Name -i "Sales_v2" --save
tx set "Sales[Amount]" -q summarizeBy -i Sum
tx set "Dates[Month]" -q sortByColumn -i MonthNo                  # empty value clears it
tx set "Sales[OrderId]" -q isKey -i true

Columns accept every writable scalar property (sourceColumn, dataType, dataCategory, summarizeBy, sortByColumn, isKey, isNullable, isUnique, isAvailableInMDX, keepUniqueRows, encodingHint, lineage tags, and more) — everything tx get shows for the column. An unsupported property name lists the full writable set; enum-valued properties list their valid values on a bad value.

mv — move or rename¶

tx mv <source> <destination> [model] [options]

Aliases: move, rename.

Renames rewrite referencing DAX automatically; --strict-refs and --no-fix-refs behave as on set.

Display folders. Middle path segments are display folders, so mv moves measures, columns, and hierarchies in and out of folders within their table (nested folders as deeper segments). A destination ending in / keeps the source name. Folder segments are only applied when either path names them — a plain rename never touches the folder the object is in; to move an object out of its folder, write the folder-qualified source. A 3-segment path that matches a hierarchy level keeps its level meaning — use -t when a level and a folder path could collide. Folder changes never affect DAX, so no reference fixup runs for them.

Measures can also move to another table (optionally renaming and picking a folder in the same step) — the classic "consolidate into a measure table" operation. A move rewrites fully-qualified 'Table'[Measure] references to the new home table; unqualified [Measure] references stay valid and are left alone. Columns, hierarchies, and partitions are bound to their table's data and cannot move.

tx mv "Sales/Old Name" "Sales/New Name" --save
tx mv tables/Sales tables/SalesData
tx mv "Sales/Total Sales" "Metrics/Total Sales" --save
tx mv "Sales/Revenue" "Sales/Finance/Revenue" --save     # into a folder
tx mv "Sales/Finance/Revenue" "Sales/Revenue" --save     # out of the folder
tx mv "Sales/Finance/Revenue" "Sales/Margins/" --save    # between folders, keep name
tx rename "Sales/Date" "Sales/CalendarDate" -t Hierarchy --save

rm — remove an object¶

tx rm <path> [model] [options]

Removal is blocked while DAX still references the object; structural references (relationships, sort-by, hierarchy levels, perspectives, role permissions) cascade-remove instead. Every object kind a mutation path can address is removable: tables, measures, columns, hierarchies, levels, partitions, calculation items, relationships, roles, role members, perspectives, cultures, shared expressions, functions, data sources, KPIs, table permissions, and calendars. A data source still bound to a partition cannot be removed until the partition is repointed or removed. A KPI shares its measure's path, so address it explicitly: tx rm "Sales/Total/KPI" or tx rm "Sales/Total" -t kpi (the measure survives; removing the measure takes its KPI with it).

tx rm "Sales/Obsolete" --dry-run
tx rm tables/Staging --save
tx rm "Sales[CustomerID] -> Customers[CustomerID]" --save

replace — find and replace¶

tx replace [pattern] [replacement] [model] [options]

--in expressions walks every expression-bearing property: measure DAX, detail-rows and format-string definitions, KPI target/status/trend, calculated columns, partition M and calculated-table DAX, refresh-policy source and polling M, calculation-group items and selection expressions, role table-permission filters, shared expressions, and DAX functions. --in names covers every renameable object, including role members; table-permission names are excluded because the engine derives them from the table. all deliberately excludes annotations — their values are often tool-generated JSON — so annotations are only touched when requested explicitly (Tabular Editor's CLI includes them in all). Whatever tx find reports for a scope, tx replace rewrites in that scope; a test enforces the pairing.

tx replace "[OrderDate]" "[ShipDate]" --dry-run
tx replace "old_name" "new_name" --in names --save

format — format DAX and M¶

tx format [model] [options]

Uses the DAX and Power Query formatter APIs. With no target, formats every expression in the model.

tx format -e "CALCULATE(sum(sales[amt]))"
tx format -p "Sales[Total Sales]" --save
tx format --save                     # whole model

script — run C# against the model¶

tx script [model] [options]

Scripts get a Model variable (the TOM model) — the escape hatch for anything the built-in commands don't cover.

tx script -e "Model.Tables.Count"
tx script transform.csx --save

incremental-refresh — refresh policies¶

tx incremental-refresh <show|set|rm|apply> <table> [options]

incremental-refresh set policy options:

tx incremental-refresh show Sales
tx incremental-refresh set Sales --rolling-window-periods 10 --rolling-window-granularity year \
  --incremental-periods 3 --incremental-granularity day --source-expression-file source.m --save
tx incremental-refresh apply Sales --no-refresh