Felix Lindhé on 24 Oct 2023 13:48:32
When creating external shortcuts (to ADLS Gen 2 DeltaLake tables) I am able to freely name my shortcuts whatever I want in the Fabric Lakehouse. This is a great functionality, and is how I expect shortcuts to behave. My underlying DeltaLake table might be named something technical to match my architecture/standards, but when making it available to end users via a Fabric Lakehouse I might want to clean up the name and present it as something more readable.
However, when creating OneLake shourtcuts between one Lakehouse to another Lakehouse i dont seem to get the same option. In this case the table in the target Lakehouse (where shortcut is created) seem to be forcibly locked to the table name in the source Lakehouse (where the managed DeltaLake table lives). This poses limitations on how you configure your solution, since you then need to name your managed DeltaLake tables to friendly names right away, or will have to present them to end users using naming standards that might not be optimal for consumption.
Imagine a case (my case) where I have a master Lakehouse containing all my orginizational marts in DeltaLake format. I have named all my tables using a naming schema that works great for that specific Lakehouse; "gold_[mart]_[fact/dim]_[tablename]". This makes sense for the purpose of this Lakehouse. However when I present this to the business users I want to do so via multiple different "mart specific" Lakehouses. In those Lakehouses I want to be able to drop the "gold_[mart]_" part of the table name, since it makes no sense in this context.
Today my master lakehouse lives in Synapse Analytics, and all my DeltaLake tables are as such mapped as external to their target Lakehouses in Fabric, meaning I can rename the shortcuts at creation and it all looks great for the end users. But were I to move in to Fabric fully - and manage all my tables inside of Fabric, I would face the issue of not being able to rename my shortcuts any longer.