HELP! Can't see uniqueidentifier fields in DirectLake semantic model

[arpost]

Greetings, all. I have a Data Warehouse where we are using UNIQUEIDENTIFIER as our primary keys for tables. When I add these tables to a DirectLake semantic model, those columns get removed. Does this mean Fabric semantic models don't support UNIQUEIDENTIFIER data types? I'd have expected these to be added as text/strings. This is kind of a big deal given that GUIDs are the only true unique key option in DW models.

[v-pagayam-msft]

Hi @arpost ,
I wanted to check in on your situation regarding the issue. Have you resolved it? If you have, please consider marking the reply that helped you or sharing your solution. It would be greatly appreciated by others in the community who may have the same question.
Thank you.

[v-pagayam-msft]

Hi @arpost ,
Thank you for reacging out to us!

This documentation data-warehouse data-types confirms that the UNIQUEIDENTIFIER data type is indeed supported in Fabric Data Warehouse.

If you are using a DirectLake semantic model, I found a known limitation which may be causing this : Spark (used in DirectLake mode) cannot currently read UNIQUEIDENTIFIER columns from Delta Lake tables generated by Data Warehouse. Because of this, such columns are may be automatically dropped from the model.

Here is a workaround which might hwlp you:

CONVERT(VARCHAR(36), YourGuidColumn) AS YourGuidText

Use this text version in your DirectLake model. This stores the uniqueness of your GUIDs and may work as a primary key alternative.

If the solution meets your requirement,consider accept it as solution.

Regards,
Pallavi.

[arpost]

Thanks for the reply, @v-pagayam-msft, and appreciate the workaround. I'm not looking forward to having to double-store data as I want values in UID format within the DW itself. Is there any status from Microsoft or feature in the works that will fix/change this?

I see this as a fairly significant limitation as it leaves us with only a few options; none of the above are ideal in my estimation:

Scenario	Comment
Use an integer with the "hacky" primary key generation approach of MAX(Key) + 1	Not feasible when running numerous concurrent write operations to the same table as this will produce duplicates. Adds orchestration overhead.
Store primary keys as strings
Use UID for PK and double-store UID as text	Adds to storage costs (albeit not a ton); adds complexity and inconsistent approaches to data (e.g., in this system we use this field but in THIS system we use that field).

[v-pagayam-msft · Accepted solution]

Hi @arpost  ,
Thanks for the detailed response!I am happy to help you.
Since there is a known limitation where Spark used in DirectLake cannot read UNIQUEIDENTIFIER columns from Delta tables created by the Data Warehouse.Microsoft team is actively working to fix the issue.Mean time I highly recommend sharing this feedback on the Fabric Ideas portal.Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.
https://ideas.fabric.microsoft.com/ideas/search-ideas/ 

Hope this helps.If so,consider accepting it as solution.

[v-pagayam-msft]

Hi @arpost ,

Could you please confirm if you've submitted this as an idea in the Ideas Forum? If so, sharing the link here would be helpful for other community members who may have similar feedback.

If we don’t hear back, we’ll go ahead and close this thread. For any further discussions or questions, please start a new thread in the Microsoft Fabric Community Forum , we’ll be happy to assist.

Thank you for being part of the Microsoft Fabric Community.