Adbc.DataSource: DirectQuery cross-table fold fails (FoldingFailureException at VisitJoinCore) despite Value.Equals returning true for identical Source bindings

[prmoore77]

Adbc.DataSource: DirectQuery cross-table fold fails with "different data sources" despite Value.Equals returning true for identical Source bindings

TL;DR

In a Power Query M custom connector that wraps Adbc.DataSource(...), two table expressions that each begin with their own Source = MyConnector.Contents(...) call (with byte-identical arguments) — exactly the M code shape that Power BI Desktop generates when a user picks two tables from the navigator into a DirectQuery model — fail to fold any cross-table join with:

Microsoft.Mashup.Engine1.Runtime.FoldingFailureException
   at Microsoft.Mashup.Engine1.Library.SqlView.SqlViewQueryDomain
       .SqlViewOptimizingQueryVisitor.VisitJoinCore(JoinQuery joinQuery)
ErrorMessage: "The left and right queries come from different data sources."

The optimizer's source-identity check is provably stricter than M language equality:

Value.Equals(MyConnector.Contents("host", port), MyConnector.Contents("host", port))
// → true

So Value.Equals says they're the same value, but VisitJoinCore rejects the fold. The optimizer is not honoring M-language equality semantics for Adbc.DataSource results.

End-user symptom: "QueryUserError" / "We couldn't fold the expression to the data source. Please try a simpler expression." in DirectQuery; the same join works in Import mode (since Import doesn't require folding to a single source).

Reproduction

Standalone, sub-second, deterministic. Uses Microsoft's own PQTest framework. No Power BI Desktop required.

1. Test connector

A minimal connector wrapping Adbc.DataSource with the Apache Arrow FlightSQL Go driver against any FlightSQL-speaking server (we used GizmoSQL — DuckDB-backed Apache Arrow Flight SQL server — but Spice.ai, Dremio, or any FlightSQL endpoint reproduces the same outcome). Connector source: https://github.com/gizmodata/gizmosql-powerbi-connector/tree/adbc-flight-sql.

2. PQTest setup

# Get PQTest from the official NuGet package
Invoke-WebRequest -Uri "https://www.nuget.org/api/v2/package/Microsoft.PowerQuery.SdkTools" -OutFile sdktools.zip
Expand-Archive sdktools.zip -DestinationPath sdktools -Force
$pqtest = (Get-ChildItem sdktools -Filter "PQTest.exe" -Recurse | Select -First 1).FullName

# Set credentials for the connector
@'
{
  "AuthenticationKind": "UsernamePassword",
  "AuthenticationProperties": { "Username": "joe", "Password": "joe" },
  "PrivacySetting": "None",
  "Permissions": []
}
'@ | & $pqtest set-credential -e GizmoSQL.mez -q probe.pq

3. Test queries

Equality.query.pq — proves M considers them equal:

let
    SourceA = GizmoSQL.Contents("localhost", 31337, false),
    SourceB = GizmoSQL.Contents("localhost", 31337, false),
    equal = Value.Equals(SourceA, SourceB)
in
    [ Value_Equals = equal ]
// Output: Value_Equals = true

Join_OneSource.query.pq — control: ONE Source binding, both tables navigate from it. Folds successfully, returns rows:

let
    Source = GizmoSQL.Contents("localhost", 31337, false),
    lineitem_Table = Source{[Name="memory",Kind="Database"]}[Data]{[Name="main",Kind="Schema"]}[Data]{[Name="lineitem",Kind="Table"]}[Data],
    orders_Table   = Source{[Name="memory",Kind="Database"]}[Data]{[Name="main",Kind="Schema"]}[Data]{[Name="orders",  Kind="Table"]}[Data],
    joined = Table.Join(lineitem_Table, {"l_orderkey"}, orders_Table, {"o_orderkey"}, JoinKind.LeftOuter, null),
    selected = Table.SelectColumns(joined, {"l_orderkey","l_extendedprice","o_orderstatus"}),
    first5 = Table.FirstN(selected, 5)
in
    first5

Join_TwoSources.query.pq — the actual failure shape that PBI Desktop generates from a DirectQuery model with two tables and a relationship: TWO Source bindings:

let
    SourceA = GizmoSQL.Contents("localhost", 31337, false),
    lineitem_Table = SourceA{[Name="memory",Kind="Database"]}[Data]{[Name="main",Kind="Schema"]}[Data]{[Name="lineitem",Kind="Table"]}[Data],

    SourceB = GizmoSQL.Contents("localhost", 31337, false),
    orders_Table = SourceB{[Name="memory",Kind="Database"]}[Data]{[Name="main",Kind="Schema"]}[Data]{[Name="orders",Kind="Table"]}[Data],

    joined = Table.Join(lineitem_Table, {"l_orderkey"}, orders_Table, {"o_orderkey"}, JoinKind.LeftOuter, null),
    selected = Table.SelectColumns(joined, {"l_orderkey","l_extendedprice","o_orderstatus"}),
    first5 = Table.FirstN(selected, 5)
in
    first5

4. Run

& $pqtest run-test -e GizmoSQL.mez -q Equality.query.pq -p
# {"Value_Equals":true}                                    ← M says equal

& $pqtest run-test -e GizmoSQL.mez -q Join_OneSource.query.pq -foff -p
# Status: Passed, RowCount: 5                              ← strict-fold mode works

& $pqtest run-test -e GizmoSQL.mez -q Join_TwoSources.query.pq -foff -p
# Status: Failed
# Error: "We couldn't fold the expression to the data source.
#         Please try a simpler expression."
# Microsoft.Data.Mashup.ErrorCode: 10704                   ← FAILURE

-foff (--failOnFoldingFailure, documented as "Force query failure when it doesn't completely fold (Direct Query behavior)") is what triggers the same fold-failure path Power BI Desktop's DirectQuery model evaluation hits.

5. Mashup engine trace excerpt

-l Engine traces from PQTest produce identical stack to Power BI Desktop's mashup container:

Engine/IO/Adbc/Connection/Open    ResourcePath: {"server":"localhost","port":31337}
                                  DriverName: ADBC Flight SQL Driver - Go
                                  DriverVersion: (unknown or development build)
                                  DBMSName: gizmosql
                                  DBMSVersion: duckdb v1.5.2
                                  Pooling: False
[...repeated 5×, identical metadata each time, fresh connection each navigation step...]

SqlViewQueryDomain/ReportFoldingFailure
   Exception: Microsoft.Mashup.Engine1.Runtime.FoldingFailureException
       at SqlViewOptimizingQueryVisitor.VisitJoinCore(JoinQuery joinQuery)
       at SqlViewOptimizingQueryVisitor.VisitJoin(JoinQuery joinQuery)
   ErrorMessage: "The left and right queries come from different data sources."

Every connection-level open shows byte-identical ResourcePath, DriverName, DriverVersion, DBMSName, DBMSVersion for both Source bindings.

6. Independent driver-side validation

Probing the same Apache Go FlightSQL driver DLL (libadbc_driver_flightsql.dll from apache/arrow-adbc release apache-arrow-adbc-23, version 1.11.0) directly via the Python adbc-driver-flightsql wheel against the same live server confirms GetInfo results are byte-identical across two independent AdbcDatabase/AdbcConnection opens with identical args:

=== Byte-for-byte equality across 2 independent connections ===
IDENTICAL across all 7 info codes.
  VENDOR_NAME           = 'gizmosql'
  VENDOR_VERSION        = 'duckdb v1.5.2'
  VENDOR_ARROW_VERSION  = '23.0.1'
  DRIVER_NAME           = 'ADBC Flight SQL Driver - Go'
  DRIVER_VERSION        = 'v1.11.0'
  DRIVER_ARROW_VERSION  = 'v18.5.2'
  DRIVER_ADBC_VERSION   = 1001000

(Note one inconsistency: the same DLL reports DriverVersion: (unknown or development build) to PBI's mashup container but 'v1.11.0' via the Python ADBC bindings. PBI's wrapper is reading the version differently than Apache's reference clients do. Probably not causal here — every per-connection open trace shows the same string — but worth flagging.)

What we ruled out

Hypothesis	Test	Result
Connector M wrapping is opaque (Diagnostics.LogValue2 etc.)	Stripped all wrappers, direct Adbc.DataSource(...) call	❌ no change
Adbc.connection.catalog/db_schema = true confuses PBI	Set both to false (matches Spice's working-config recipe)	❌ no change
Missing NativeQueryProperties.EnableFolding = true	Added	❌ no change
Wrong navigationSteps shape	Replaced {[]} placeholder with full 3-level Catalog→Schema→Table descriptor	❌ no change
Inline lambda in Value.ReplaceType (vs named function)	Refactored to named GizmoSqlConnectionImpl (matches Spice's named SpiceConnectionImpl)	❌ no change
Extension.CurrentCredential() is non-deterministic	Hardcoded credentials in M	❌ no change
Result needs explicit Value.ReplaceMetadata([DataSource.Kind=..., DataSource.Path=...])	Added	❌ no change
Stale PBI Desktop caches	Cleared Cache, ExtensionCache, FoldedArtifactsCache, LuciaCache, fresh PBIX	❌ no change
Stale model state in saved PBIX	Tested with brand-new blank PBIX	❌ no change
Server-side metadata varies per connection	Inspected gizmosql/duckdb_sql_info.cpp:200-206: all FLIGHT_SQL_SERVER_* strings are compile-time constants	❌ deterministic
Driver-side metadata varies per call	Reviewed apache/arrow-adbc/go/adbc/driver/flightsql/flightsql_driver.go:69 + driver_info.go: all defaults are constants	❌ deterministic

What we believe is wrong

The mashup engine's data-source-identity check inside Microsoft.Mashup.Engine1.Library.SqlView.SqlViewQueryDomain.SqlViewOptimizingQueryVisitor.VisitJoinCore is using stricter-than-Value.Equals equality on the values returned by Adbc.DataSource. We believe the check is comparing wrapped CLR-object identity (per-call) rather than configuration-value equality (which would correctly hash-equate two calls with byte-identical arguments).

Odbc.DataSource does not exhibit this — the v1.x ODBC version of this same connector (against the same backend) folds cross-table joins in DirectQuery without issue. Microsoft's certified ADBC connectors (Databricks, Snowflake, Dremio, BigQuery, Impala) also fold cross-table joins in DirectQuery. So either:

• those certified connectors ship through a private partner channel that opts into different optimizer behavior, or
• their backing ADBC drivers expose a piece of metadata that Apache's Go FlightSQL driver doesn't.

Either way, the recipe Apache + Spice + this connector are following — which is the only public ADBC custom-connector recipe — produces non-foldable cross-table joins in DirectQuery.

Related public reports

• spiceai/powerbi-connector#10 — "Adding Table Relationships causes 'We couldn't fold the expression to the data source.' error". Independent reproduction on a different ADBC backend (Spice.ai instead of GizmoSQL). Open, no maintainer response, no workaround.
• mariadb-corporation/mariadb-powerbi#12 — Same fold-failure error on a different (non-ADBC) custom connector. Closed without resolution.
• Microsoft Fabric: ADBC LEFT JOIN UnknownError — different ADBC error path. Community consensus: "the new ADBC implementation provides extremely poor messaging compared to previous versions."
• Microsoft Fabric: Table.Join + DirectQuery — Microsoft Community Support confirms the design rule: "tables must originate from the same SQL database for Table.Join to function properly in DirectQuery mode". The "different data sources" check is intentional; the bug is that it's mistakenly identifying same-source as different-source for Adbc.DataSource.

Environment

• Power BI Desktop: 2.153.777.0 (26.04 / April 2026)
• Connector: gizmodata/gizmosql-powerbi-connector adbc-flight-sql branch
• ADBC FlightSQL driver: apache/arrow-adbc release apache-arrow-adbc-23 (driver version 1.11.0, Go-built)
• Backend: GizmoSQL v1.24.0 (DuckDB v1.5.2)
• PQTest: Microsoft.PowerQuery.SdkTools (latest from NuGet)

What would help

1. Documentation of what Power BI's mashup-engine optimizer uses for the Adbc.DataSource source-identity check, so connector authors can align with it.
2. Either: change the check to honor Value.Equals semantics (treat two Adbc.DataSource(driver, conn, opts) calls with structurally-equal args as the same source), or expose a connector-level mechanism to declare "two calls with these args produce the same data source" — analogous to whatever the certified-partner connectors are using.
3. A standardized, public way for ADBC custom connectors to participate in DirectQuery cross-table folding, since the closed-source path used by certified Microsoft partners is the only one that currently works.

[mattmasson]

As I mentioned in #393 - we're still evolving our ADBC extensibility APIs and won't be posting public docs or guidance for using the functions until we're relatively certain things aren't going to change. At this point they should be considered experimental.

For example - more recent versions of the API use Adbc.Connection instead of Adbc.DataSource, and there is a new SqlView.Generator function for configuring the query folding implementation. The first argument to SqlView.Generator is a "unique identifier" value used to determine if two queries point to the same data source. Ensuring both GizmoSQL.Contents calls resolve to the same unique identifier would resolve the issue reported here.

[prmoore77]

Thank you for the tips, @mattmason!

[prmoore77]

Thanks @mattmasson — I tried to implement your suggestion and want to share the probe data and one important data point that broadens the scope before asking a targeted follow-up.

The same bug also fires on the ODBC kernel (which isn't experimental)

Before getting into the ADBC experiment, worth flagging: our v1.1.2 release is built on Odbc.DataSource — the documented, long-stable kernel — and exhibits the same "different data sources" rejection in DirectQuery cross-table joins. Same M-level shape (two GizmoSQL.Contents(...) calls navigated to different tables, then Table.Join). Server --print-queries log confirms no SQL ever reaches the driver, so the rejection happens entirely inside SqlViewOptimizingQueryVisitor.VisitJoinCore before fold-out — it can't be a driver-side issue on either kernel.

So this isn't an ADBC-only problem; it's a generic-kernel problem. Odbc.DataSource and Adbc.DataSource both lack any way for a custom connector to declare source identity. Built-in functions (Sql.Database, Snowflake.Databases, Databricks.Catalogs, etc.) appear to be on separate optimizer paths and don't hit this rejection.

ADBC probe results

Tested against:

• PQTest / Mashup Engine 2.154.528.0 (current Power Query SDK)
• Power BI Desktop 2.153.1206.0 (latest available — April 2026 / 26.04 with current QFE; May 2026's "update" didn't bump the engine family)

(Note: PQTest's mashup engine is one minor version ahead of what's currently in PBI Desktop. The new functions discussed below are reachable in PQTest 2.154 but may not be present at all in shipped PBI Desktop 2.153 — our try #shared[Adbc.Connection] otherwise null warmup in the connector silently falls through there.)

Function	Signature	Status
Adbc.Connection	(driver, databaseProperties, connectionProperties, optional options)	Exposed. Returns a connection-handle record (ExecuteQuery, ExecuteStatement, GetObjects, GetTableSchema, …). Options accept only {AdditionalCacheKey, ConnectionPoolType} — SqlGenerator is rejected here.
SqlView.Generator	(uniqueIdentifier, sqlGenerator, getData)	Exposed. Returns a function (fromItem, fromItemType, context) => ?.
Adbc.DataSource	unchanged	Options: {ClientConnectionPooling, CreateNavigationProperties, CredentialConnectionString, SqlGenerator}. No slot for a SqlView.Generator value, no AdditionalCacheKey. The v1 SqlGenerator record validator rejects adding SqlView/UniqueIdentifier fields ("provided options are not valid").
Adbc.Query	(driver, connectionProperties, query, optional options)	Exposed. Options: {Catalog, ClientConnectionPooling, CredentialConnectionString, IsMetadata, StatementProperties}. No folding/identity slot.
SqlView.DataSource, SqlView.Query	Strings present in Microsoft.MashupEngine.dll (internal classes SqlViewDataSource, SqlViewModule, etc.)	NOT exposed in #shared in either build.

The missing bridge

Following SqlView.Generator's return-type back through the engine namespace, its output is shaped to be invoked by the engine during fold-out — we supply the ingredients (sqlGenerator rules, getData executor, uniqueIdentifier hash) and the engine calls back into the returned function with (fromItem, fromItemType, context) to materialize.

What's missing for a custom connector is a way to register a SqlView.Generator with a navigator entry so the engine knows "consult this SqlView when folding operations against this table." Of the four candidate registration paths, none works in current builds:

1. Adbc.DataSource options — closed list, no SqlView slot
2. Adbc.Connection options — closed list, no SqlView slot
3. SqlView.DataSource(connection, viewGenerator) → navigator-table — internal class exists, not exposed
4. SqlView.Query(viewGenerator, sql) → foldable-table — internal class exists, not exposed

I also tried a side-effect warmup (Adbc.Connection(..., [AdditionalCacheKey = uid]) immediately before Adbc.DataSource) so the cache-key would be pre-registered on the pool — no effect on the source-identity hash; cross-table joins still fail identically.

Hand-building a navigator from Connection[GetObjects] + Table.View doesn't help either: Table.View handlers have a fixed set of signatures (OnTake, OnSelectColumns, OnSelectRows, etc.) that don't match the (fromItem, fromItemType, context) shape, so there's no M-level way to bridge them to a SqlView callable. M-value identity (Value.Equals) does report two GizmoSQL.Contents(...) calls as equal, but the optimizer demonstrably doesn't consult it for this decision.

Questions

1. Are SqlView.DataSource and SqlView.Query (the internal classes visible in the engine DLL) the intended bridge from a custom connector to the SqlView.Generator-based identity mechanism? There appear to be two timeline layers here, both of which matter to custom-connector authors:
   • When will those functions be exposed in #shared (i.e., reachable from M) in the SDK / PQTest engine?
   • When will the engine version that exposes them be promoted into Power BI Desktop? The SDK currently runs one mashup engine ahead of shipped PBI Desktop, so even after (a) lands in PQTest, custom connectors can't actually ship to end users until (b).
2. Once that path lands, is the unique-identifier mechanism intended to cover the ODBC kernel as well? The ODBC path isn't experimental and presumably can't be deprecated, so a fix there would meaningfully change what custom-connector authors can deliver in DirectQuery today.
3. In the meantime, is there a preview build or undocumented pattern we could test against? Happy to repro on whatever's useful.

Repro: https://github.com/gizmodata/gizmosql-powerbi-connector (branch adbc-flight-sql). Full probe transcript and test-query files available on request.

[CurtHagenlocher]

There are no "references" in the definition of M, so equality in M is based strictly on value equality. If two different data sources return exactly the same data, then the result of Value.Equals(DataSource.1(arg1, arg2), DataSource.2(arg3)) might well be true.

When you run inside Power BI desktop with tracing maximally enabled, are you seeing any specific warnings in the traces related to the failed attempt to produce the join? Most of the checks to see whether folding is supported will write some kind of indicator into the traces to help debug this.

[prmoore77]

Thanks @CurtHagenlocher — point taken on Value.Equals. You're right that without references, structural equality doesn't carry source identity; we were leaning on that too hard. I'll drop the argument.

On the trace front: with HKCU\Software\Microsoft\Microsoft Power BI Desktop\TracingEnabled = 1 and TracingLevel = 15, the failed cross-table join (Activity 72bd9c6d-48e1-4273-8a04-c4772a57a596, PBI Desktop 2.153.1206.0) emits these events in %LOCALAPPDATA%\Microsoft\Power BI Desktop\Traces\Performance\*.log:

SqlViewQuery/FoldingWarning             "Function Name": "VisitJoinCore"

SqlViewQuery/FoldingWarning             "ErrorMessage":  "The left and right queries come from different data sources."

SqlViewQueryDomain/ReportFoldingFailure FoldingFailureException
   at Microsoft.Mashup.Engine1.Library.SqlView.SqlViewQueryDomain.SqlViewOptimizingQueryVisitor.VisitJoinCore(JoinQuery joinQuery)
   at Microsoft.Mashup.Engine1.Library.SqlView.SqlViewQueryDomain.SqlViewOptimizingQueryVisitor.VisitJoin(JoinQuery joinQuery)

The one wrinkle that surprised me — in the same activity, immediately before the fold-failure, SqlExpressionTranslator/Translate reports IsRecognized: True and SqlTranslator/SqlParser/Parse shows a fully-formed JOIN SQL was generated against the connector:

SELECT TOP (1000001) *
FROM (
    SELECT [t1].[o_shippriority], SUM([t0].[l_extendedprice]) AS [a0]
    FROM ([lineitem] AS [t0]
          LEFT OUTER JOIN [orders] AS [t1] on ([t0].[l_orderkey] = [t1].[o_orderkey]))
    GROUP BY [t1].[o_shippriority]
) AS [MainTable]
WHERE (NOT ([a0] IS NULL))

So the SqlGenerator did produce a valid folded JOIN. VisitJoinCore then walks the join AST and discards the already-generated SQL — the rejection is at the source-identity check, not at the fold-rules level.

Follow-up question: at this trace level we can see the outcome (FoldingFailure / "different data sources"), but we can't see what VisitJoinCore is comparing to reach that conclusion. Is there a deeper trace knob that emits the actual operands of the source-identity check (cache keys, query-domain handles, whatever the equivalence-class identity is)? Or could you share at a high level what VisitJoinCore's same-source predicate looks at? Knowing whether it's connection-properties hashing, AdbcQueryDomain references, an internal cache-key chain, etc. would tell us whether there's anything a custom connector can do today (vs. waiting on the new SqlView.Generator / SqlView.DataSource path Matt mentioned) to make the two sides hash-equate.

Repro stays at https://github.com/gizmodata/gizmosql-powerbi-connector (branch adbc-flight-sql); full trace file available if useful.

[CurtHagenlocher]

That SqlExpressionTranslator/Translate entry is a bit misleading. The way the pipeline works is that AS sends us a SQL query (which is the one you see in that trace entry). We then translate the SQL query into an M query (which is also logged to the traces). The M query is then evaluated, which is what triggers the folding process. The end result is that we're translating SQL -> M -> SQL, and the final result can look very similar to the original. Whether or not this is a "good idea" is perhaps debatable; in principle, it enables a lot of scenarios that in practice might not be relevant all that often.

Failing on that particular comparison implies that the two sides of the join have different values for the data source path. I don't see any other reason it would trigger. But that should imply that we wouldn't even have gotten this far in the code, so I don't know what to make of it. Is there any reason to think the data source paths might be different for some reason? If you structure your queries in PQ so that there's a single shared member that creates the data source and the individual tables reference that member instead of calling the data source function individually, does it make a difference?

[prmoore77]

Tested as you suggested, @CurtHagenlocher — single shared Source member referenced from both table queries — and the cross-table join folded all the way through to the server. Concrete evidence from this run:

M structure (in Power Query Editor):

// Query: Source  (Enable load = false)
let
    Source = GizmoSQL.Contents("localhost", 31337, false)
in
    Source

// Query: lineitem
let
    memory_Database = Source{[Name="memory", Kind="Database"]}[Data],
    main_Schema    = memory_Database{[Name="main", Kind="Schema"]}[Data],
    lineitem_Table = main_Schema{[Name="lineitem", Kind="Table"]}[Data]
in
    lineitem_Table

// Query: orders  (same shape, navigating to "orders")

Result (PBI Desktop 2.153.1206.0, DirectQuery, activity 35d763d3-1d96-4fe0-bce3-ae9face752cc):

• No SqlViewQuery/FoldingWarning or SqlViewQueryDomain/ReportFoldingFailure events in the trace

• Engine/IO/Adbc/Command/ExecuteDirect carries the folded LEFT OUTER JOIN end-to-end:

  select "o_orderstatus", "o_shippriority", "C1"
  from (
      select "o_orderstatus", "o_shippriority", SUM("l_extendedprice") as "C1"
      from (
          select "OTBL"."l_extendedprice", "ITBL"."o_orderstatus", "ITBL"."o_shippriority"
          from "memory"."main"."lineitem" as "OTBL"
          left outer join "memory"."main"."orders" as "ITBL"
              on ("OTBL"."l_orderkey" = "ITBL"."o_orderkey")
      ) as "ITBL"
      group by "o_orderstatus", "o_shippriority"
  ) as "ITBL"
  where not "C1" is null
  limit 1000001

• GizmoSQL server log confirms the JOIN SQL was received and executed.

So your diagnosis is correct: the per-table-source pattern (each query starts with its own Source = GizmoSQL.Contents(...)) produces source-identity bindings that don't hash-equate inside VisitJoinCore, even though the args are byte-identical; the single-shared-Source pattern does.

The UX gap that still bites custom-connector users:

Power BI Desktop's default Get Data → Navigator flow generates the per-table-source pattern automatically — every selected table comes back as its own query with Source = GizmoSQL.Contents(...) baked in. So out-of-the-box, any user of a custom ADBC/ODBC connector who adds two tables via the Navigator hits this in DirectQuery the moment they try a cross-table relationship. Without prior knowledge that "fold the Sources into one shared member" is the workaround, they just see QueryUserError with no actionable signal.

That maps onto two questions, if you can speak to either:

1. Is there a way for a connector author to influence what M Get Data emits — e.g., a Publish/DataSource flag that tells the Navigator to consolidate to a shared Source member when multiple tables from the same data source are loaded — so the default UX produces a foldable model?
2. Or is the long-term answer the SqlView.Generator(uniqueIdentifier, …) path Matt mentioned, where the optimizer learns to recognize same-args connector calls as same-source regardless of M structure? (If yes, that's our cue to wait for the new API to land in PBI Desktop and accept that the workaround is the documented advice in the meantime.)

Either way — appreciate you nailing the comparison happening inside VisitJoinCore; that's the unblocking insight. Happy to share the full trace file if useful.

[CurtHagenlocher]

Right, I wasn't suggesting that users do this; only trying to use this result to narrow down the problem. The next step would be to go back to the failure case and try to capture the traces when refreshing both the orders table and the lineitem table. Some of the traces associated with each of those should have ResourceKind and ResourcePath fields on them, where the kind is GizmoSQL and the path is a JSON representation of your function arguments. The error message you're getting implies that the ResourcePath for the two different tables are different for some reason. Is that what you see in the traces?

[prmoore77]

Thanks @CurtHagenlocher — captured both ResourceKind/ResourcePath from the failure run and the success run, side-by-side. Short answer: the ResourcePath is byte-identical for both tables in both runs. The "different data sources" rejection isn't driven by anything we can see at the ResourcePath level.

Failure run (per-table-source pattern, Activity 72bd9c6d-48e1-4273-8a04-c4772a57a596)

M shape (each table has its own Source = GizmoSQL.Contents(...)):

// Query: orders
let
    Source = GizmoSQL.Contents("localhost", 31337, false),
    memory_Database = Source{[Name="memory", Kind="Database"]}[Data],
    main_Schema    = memory_Database{[Name="main", Kind="Schema"]}[Data],
    orders_Table   = main_Schema{[Name="orders", Kind="Table"]}[Data]
in
    orders_Table

// Query: lineitem  (same shape, navigating to "lineitem")

Distinct (PartitionKey, ResourcePath) pairs across the run (deduplicated):

Action	PartitionKey	ResourceKind	ResourcePath
Engine/IO/Adbc/Command/GetTypeInfo	Section1/orders/orders_Table	GizmoSQL	{"server":"localhost","port":31337}
Engine/IO/Adbc/Command/ExecuteDirect	Section1/orders/orders_Table	GizmoSQL	{"server":"localhost","port":31337}
Engine/IO/Adbc/Command/GetTypeInfo	Section1/lineitem/lineitem_Table	GizmoSQL	{"server":"localhost","port":31337}
Engine/IO/Adbc/Command/ExecuteDirect	Section1/lineitem/lineitem_Table	GizmoSQL	{"server":"localhost","port":31337}
Engine/IO/Adbc/Command/GetTypeInfo	Expression/Expression (the join)	GizmoSQL	{"server":"localhost","port":31337}

Then in the same Activity, immediately after the Expression/Expression GetTypeInfo:

SqlViewQuery/FoldingWarning             "Function Name": "VisitJoinCore"
SqlViewQuery/FoldingWarning             "ErrorMessage":  "The left and right queries come from different data sources."
SqlViewQueryDomain/ReportFoldingFailure FoldingFailureException
   at Microsoft.Mashup.Engine1.Library.SqlView.SqlViewQueryDomain.SqlViewOptimizingQueryVisitor.VisitJoinCore(JoinQuery joinQuery)

So both per-table refreshes emit the same ResourceKind=GizmoSQL + ResourcePath={"server":"localhost","port":31337}, the join expression itself emits the same, and VisitJoinCore still concludes "different data sources."

Success run (shared-Source pattern, Activity 35d763d3-1d96-4fe0-bce3-ae9face752cc)

For completeness — distinct pairs from the working version:

PartitionKey	ResourcePath
Section1/Source/Source	{"server":"localhost","port":31337}
Section1/lineitem/lineitem_Table	{"server":"localhost","port":31337}
Section1/orders/orders_Table	{"server":"localhost","port":31337}
Expression/Expression (the folded join)	{"server":"localhost","port":31337}

Identical ResourcePath everywhere — same as the failure run. The only structural difference is the M layout: shared Source query vs. per-table Source = GizmoSQL.Contents(...).

What this tells us

1. ResourcePath as surfaced in traces is not the value VisitJoinCore is comparing, since it matches across both tables (and across both M patterns). Whatever identity layer rejects the per-table-source case is below or beside ResourcePath.
2. The ResourcePath JSON contains only the required function arguments (server, port) — the optional ones (useEncryption, disableCertificateVerification, defaultCatalog) are dropped from the path, even when passed explicitly. So it's already a normalized form, not the raw arg tuple.
3. The PartitionKey differs between the two refreshes (Section1/orders/... vs Section1/lineitem/...), but that reflects the M section/binding path, not source identity. Same PartitionKey segment is present in the success run too.

Question back

Given the ResourcePath is identical, what is the comparison inside VisitJoinCore actually keyed on? Some candidates we've considered:

• The M sub-expression that produces the navigator-rooted value (i.e., the GizmoSQL.Contents(...) invocation node itself, compared as expression-tree identity rather than value identity) — would explain why two textually-identical calls in two separate Source bindings hash differently, while one shared Source binding referenced twice hash-equates.
• The internal cache/pool key the kernel registers for an open ADBC connection — but AdditionalCacheKey via Adbc.Connection had no effect, suggesting that's not what's consulted.
• A QueryDomain / SqlViewQueryDomain reference inside the optimizer that gets minted per-binding rather than per-args.

If it's the first one (expression-tree identity of the GizmoSQL.Contents node), that explains everything we're seeing and makes the workaround intrinsic to the optimizer's design — Adbc.DataSource callers can't influence it from outside. If it's something else, knowing what would tell us whether there's any connector-side knob.

Full trace files for both Activities attached (issue-409-pbi-traces.zip) — contains:

• Microsoft.Mashup.Container.NetFX45.5576.2026-05-13T15-42-23-235487.log — failure run (per-table-source), Activity 72bd9c6d-…. The VisitJoinCore stack and the two table refreshes' ResourcePath emissions are at lines 15, 18, 29, 32, 37, 40, 45, 48, 53, 54, 57–59.
• Microsoft.Mashup.Container.NetFX45.2840.2026-05-13T17-58-10-087795.log + .728.2026-05-13T18-06-22-…log — success run (shared-Source), Activity 35d763d3-…, including the folded LEFT OUTER JOIN SQL in Engine/IO/Adbc/Command/ExecuteDirect.