How Weaver works

The whole path

Build and load are separate. You can create or change the Fabric structure first, then move data when you are ready.

1. Your project is the files you write

Put each Python or SQL object under the Lakehouse or Warehouse that owns it. The folder structure makes the Fabric project visible in source control.

workspace: Analytics
catalogue: Warehouse/Catalogue

targets:
  Lakehouse/Landing: Landing_Dev
  Warehouse/Curated: Curated_Dev

Your code still uses Lakehouse/Landing and Warehouse/Curated. Change this file to point the same project at production.

2. Build creates or changes the Fabric objects

weaver build compares the project with Fabric and makes the required changes.

It creates schemas, folders, Delta tables, Warehouse tables and views, shortcuts, checks and the code used by later loads. It does not load the data.

When one object changes, Weaver also rebuilds the downstream objects affected by that change. It leaves unrelated work alone.

3. Weaver records what exists and what happened

Weaver stores this information in a Catalogue Warehouse in Fabric.

After a failure, the next run can see which work finished and which work still needs attention.

4. Load, test and health use that record

If an upstream table loads again, Weaver can tell that downstream data is now stale even when its previous load succeeded.

Weaver reads dependencies from the code

Your imports and SQL references already describe the order. Weaver uses them instead of asking you to repeat it in another pipeline.

Python

from Files.Sales__Customers import Sales__Customers
from weaver import Table

class Sales__Customer(Table):
    def read(self):
        exported = Sales__Customers(self).spark_path()
        return (
            self.spark.read.option("header", True)
            .csv(exported)
            .selectExpr("`Customer id`", "`Customer name`", "`Region code`")
            .dropDuplicates(["Customer id"])
        )

The import tells Weaver to load the customer files before the Delta table.

T-SQL

select c.[Customer id]
     , c.[Customer name]
     , r.[Region name]
  from [Sales].[Customer] c
  join [Sales].[Region] r
    on r.[Region code] = c.[Region code];

The query tells Weaver to load both Warehouse relations before the join. If one comes from a Lakehouse shortcut, Weaver still puts the work in the right order.

See it run