u/Affectionate-Top137

I finally got a ticket for the fifa R16 this Monday. And the Portugal jerseys are sold out everywhere. I would appreciate if anyone could sell or rent me the jersey for a day.
Thanks!

I finally got a ticket for the R16 this Monday. And the Portugal jerseys are sold out everywhere. I would appreciate if anyone could sell or rent me the jersey for a day.
Thanks!

UPDATE: Thanks for everyone! I got the last one from soccer city.

I am new to warehousing and fabric.

Looking for advice on our current workflow and whether there's a cleaner industry-standard approach.

Our setup:
- Microsoft Fabric Warehouse with Git integration (repo-synced workspace)
- We apply schema changes via migration scripts (`ALTER TABLE`, `CREATE OR ALTER PROCEDURE`) run directly against the SQL endpoint via a MigrationRunner
- We never edit the warehouse snapshot files (`DEV_DW.Warehouse/**`) directly because Fabric's Git sync will DROP and recreate the object — deleting all data

The problem:
Our workflow currently requires two separate PRs for every schema change:

1. PR #1 — merge migration scripts → pipeline runs them against the warehouse → schema is updated live
2. PR #2 — manually export the updated object definitions from Fabric and commit them back to master so the snapshot reflects the new state

The second PR is fully manual, easy to forget, and feels wrong.

Questions:

1. Is this a solved problem for Fabric Warehouse specifically? Any native tooling we're missing?
2. Is the snapshot worth maintaining at all, or should we just treat migration scripts as the sole source of truth and drop the warehouse folder entirely?
3. Has anyone used Fabric SQL Database Projects to avoid this? Does it handle the drop/recreate problem intelligently?

Any experience with this pattern or best practices are appreciated.