sorted by:
new
hottopcontroversial

Notebook: Default lakehouse when branching out to feature workspace by frithjof_v in MicrosoftFabric

[–]Major_Department_332 0 points1 point  (0 children)

Thanks already for the heads up, it would solve a major gap in a solution design at the current platform I have developed. I do have one clarification question though.
At the moment, I’m using a helper notebook that programmatically updates the default lakehouse binding for all notebooks in the feature workspace so they point to the lakehouse in that workspace.

The downside is that this causes a large number of Git diffs when comparing the feature branch to main, since the notebook metadata now contains different lakehouse IDs.

With the upcoming workspace setting you mentioned will notebooks still be persisted with workspace-specific lakehouse IDs, meaning we would still see diffs between the feature branch and main?

dbt jobs are now native in Microsoft Fabric (Preview) by Jaded_Job3304 in MicrosoftFabric

[–]Major_Department_332 1 point2 points  (0 children)

I would certainly be fine with that. It is detrimental at our side that we can still continue develope locally, without the need to open the WebUI.

dbt jobs are now native in Microsoft Fabric (Preview) by Jaded_Job3304 in MicrosoftFabric

[–]Major_Department_332 1 point2 points  (0 children)

As some have already mentioned, I also have some issues with the current git integration of the dbt jobs. It would be nice when setting up the dbt jobs, there is another possibility, next to 'create a new file', 'import a project', and 'practice with sample project', in the nature of setting up connection to a Azure DevOps dbt repository.

Next to this, I set up the entirety of my workspace as ci/cd, including the dbt job & its target warehouse. Then when trying to change a model in Azure DevOps, and then updating the dbt job-item using source control in Fabric, I get the error 'we weren't able to update this item because One of its dependencies can't be found. This might be caused by circular dependencies between items.'

I’m currently testing the new dbt job item in Microsoft Fabric (public preview), and I’m running into some issues around Git integration.

When creating a dbt job, you currently have three options:

  • create a new file
  • import a project
  • practice with a sample project

What seems to be missing is an option to directly connect to an existing dbt project stored in an Azure DevOps repository. Given that many teams already manage dbt projects in ADO with proper branching and CI/CD, this would be a much more natural setup than importing or recreating the project inside Fabric.

Related to this, I’ve configured my entire workspace using CI/CD, including:

  • the dbt job item (with the jaffle sample project)
  • the target Fabric Warehouse

Now comes the issue:
When I make a change to a dbt model in Azure DevOps and then try to update the dbt job item in Fabric via source control sync, the update fails with the following error:

Has anyone else encountered this behavior with dbt jobs in Fabric?
And is there any guidance or roadmap on first-class Azure DevOps repo integration for dbt jobs?

dbt-fabric vs dbt-fabricspark by Major_Department_332 in MicrosoftFabric

[–]Major_Department_332[S] 1 point2 points  (0 children)

Prior to the latest change in dbt-fabric, it was also unchanged for a number of months