Forum Discussion

Element115's avatar
Element115
Memorable Member
2 years ago
Solved

BUG or FEATURE???::DirectLake mode not supported

It appears that because the semantic model was created with two DFg2 that output the data into a lakehouse, so the lakehouse is the semantic model, all connections to the table are by default in Dire...
  • Element115's avatar
    Element115
    2 years ago

    And wouldn't you know it... you have to go traipsing through a labyrinthine thicket of uncommon sense and other assorted illogical UI paths.  So here is the solution to connect to lakehouse tables in DirectQuery mode--the long and short of it, you need to figure out where the option to connect to the lakehouse SQL endpoint is, and once you do, select that and badabing-badaboom!, you are in business.  Totally ridiculous UI/UX design if you ask me (not to mention that the previous attempts do not generate any visual feedback to let you know what the hell is going on), but there you've it:

     

     

  • Element115's avatar
    Element115
    2 years ago

    Just a simple CREATE VIEW where I select a computed col in addition to all the cols from the source table.  I'd be curious to learn what's the best approach though, in terms of efficiency and so on.  What happens each time a report queries the lakehouse table (in DirectQuery or DirectLake mode)?  Is the view recomputed from scratch every single time?  Or does Fabric use materialized views like Oracle?  The underlying data store being managed by Microsoft, I'd assume they configure it so that it is optimized for READ speed, but who knows, right?  

    I also heard you actually can WRITE to a lakehouse table, instead of just creating a virtual table, but only if using PySpark in a notebook.  Haven't tried yet.   

     

    DROP VIEW vTABLE_CALC_COL;
    GO
    CREATE VIEW vTABLE_CALC_COL
    AS
        SELECT  *, ([count] /2 ) AS calcol
        FROM Data_15M

     

    The new calculated col, calcol, then shows up in dataflows and models.