Skip to main content

Lesson 6 — Your first source and table

What you'll be able to do: read and write the two YAML files that add a table to the platform — a connection and an object — and predict what they generate.

This is the first hands-on lesson. You don't need a Fabric environment; the goal is to read real config and know exactly what each line does. We'll use the demo's AdvWorks CSV source.

Step 1 — Describe the source (the connection)​

A connection answers "how do we reach this source, and what does its data look like?" — once, for every table from that source.

ConnectionName: adv-advworks
ConnectionPrefix: adv
ConnectionType: fabricfiles
BronzeFolder: advworks
FileType: csv
FileExtension: csv
Delimiter: ","
Header: true
Multiline: true
Escape: '"'
Dateformat: "yyyy-M-d"

Reading it line by line:

  • ConnectionType: fabricfiles — the source is files sitting in Fabric's own Files area. (Other types cover Azure Blob storage, or a custom notebook connector for anything unusual.)
  • BronzeFolder: advworks — where in the Bronze lakehouse the incoming files land.
  • FileType / Delimiter / Header / Escape / Dateformat — how to parse the CSV. Set here once, inherited by every object that uses this connection.
  • ConnectionPrefix: adv — prefixes generated object names, so tables from different sources don't collide.

Step 2 — Describe the table (the object)​

An object answers "what table do I want, and what are its columns?"

Table:
  Connection: adv-advworks
  SourceTable: customers.csv
  DataPlatformObjectname: customers
  KeepHistory: true
  Columns:
  - SourceColumn: CustomerID
    SourceDataType: int
    IsPrimaryKey: true
  - SourceColumn: FirstName
    SourceDataType: varchar(255)
  - SourceColumn: LastName
    SourceDataType: varchar(255)
  - SourceColumn: EmailAddress
    SourceDataType: varchar(500)

Reading it:

  • Connection: adv-advworks — links this table to the connection above, inheriting all its parsing settings. This is the reuse from Lesson 5 in action.
  • SourceTable: customers.csv — what to read from the source. (For file sources it's the file/folder name; for database sources it would be the table name. The field is named SourceTable for historical reasons.)
  • DataPlatformObjectname: customers — what the table is called inside your platform.
  • KeepHistory: true — track how rows change over time. This needs a primary key…
  • IsPrimaryKey: true on CustomerID — …which this provides. It's how history knows whether an incoming row is new, updated, or unchanged.

What this produces​

From those two files, a deploy creates — empty (schema-on-write, Lesson 3):

  • a Bronze landing table for the raw customers.csv rows,
  • a Bronze history table (because KeepHistory: true + a primary key),
  • a Silver customers table with cleaned, typed columns.

You wrote what; the framework produced the medallion how. No CREATE TABLE, no Spark, no history logic written by hand.

The fast path

In a real project you rarely start from a blank file. Ask the add-source skill in Claude Code — "add a source from Azure SQL", "connect to this blob storage" — and it checks whether a built-in loader already fits before scaffolding the connection and object YAML for you. Full field references: Connection config and Object config.

Check your understanding​

You set KeepHistory: true but no column has IsPrimaryKey: true. What's wrong?

History can't work without a key. To record whether an incoming row is new, updated, or unchanged, EasyFabric has to match it against existing rows — and that match needs a primary key. Keeping history requires at least one primary-key column.

You have ten CSV tables from the same AdvWorks export. Where do you put the delimiter and date format — in each object, or the connection? Why?

In the connection. Parsing settings describe the source, and all ten tables share it, so you set them once on adv-advworks and every object inherits them. Putting them on each object would be ten copies to keep in sync — the exact drift the connection/object split is designed to avoid.

Right after deploying this, does customers contain the CSV's rows?

No — deploy created the empty shapes. The rows arrive in the next step, loading, which is Lesson 7.

Recap​

  • Adding a table is two files: a connection (how to reach + parse the source, shared) and an object (one table's columns, per-table).
  • KeepHistory needs a primary key; that key is how history classifies each incoming row.
  • The result is Bronze + history + Silver tables — generated, empty, ready to load.

Next: fill those tables — Loading data end-to-end →