refactor(sql): dialect-owned parameter markers, bind names and command configuration

ISqlDialect gains ParameterMarker (the token in the SQL text), ParameterBindName (the DbParameter.ParameterName) and ConfigureCommand (per-command provider setup, where Oracle will set BindByName). SQL Server and the test SQLite dialect answer "@"+name for both spellings and no-op the hook, so SQL Server behaviour is byte-identical — every existing expected-SQL assertion passes untouched. SqlGroupPlanner drops its hardcoded @k/@w consts and mints base names (k0..kN, w) that the dialect spells; SqlQueryPlan carries the emitted markers AND the matching bind names, so SqlPollReader keeps copying the plan's pairing rather than re-deriving a provider convention (the two diverge on ODP.NET: ":k0" in the text, bare "k0" on the parameter). SqlCatalogLoader and SqlBrowseSession bind schema/table through the dialect, so their bind names cannot drift from the markers in the dialect-owned catalog SQL. Every parameter-carrying command site calls ConfigureCommand before its first parameter. Controlled by a new test-only ColonMarkerDialect (":name" markers, bare bind names) that really executes against the SQLite fixture. Each leg was falsified against the pre-change behaviour: the planner emitted "@k0", the reader bound ":k0", and a hardcoded "@schema" in the loader failed catalog load outright.
2026-08-05 06:25:53 -04:00
parent 08c1728a98
commit 1da770253e
16 changed files with 527 additions and 36 deletions
@@ -371,4 +371,31 @@ public sealed class SqlBrowseSessionTests
        await session.AttributesAsync(columnNodeId, CancellationToken.None);
        session.LastUsedUtc.ShouldBeGreaterThan(afterExpand);
    }
+
+    /// <summary>
+    ///     The browse path binds the <em>dialect's</em> parameter names, not a hardcoded <c>"@schema"</c>.
+    ///     Driven through <see cref="ColonMarkerDialect"/> (markers <c>:schema</c>/<c>:table</c>, bare bind
+    ///     names) — ODP.NET's shape, and the only place the two spellings differ.
+    ///     <para>Discriminating in two independent ways: a session still binding <c>"@schema"</c> leaves the
+    ///     colon marker unbound (the expand yields nothing, or the provider refuses the command), and the
+    ///     recorded names would carry the prefix.</para>
+    /// </summary>
+    [Fact]
+    public async Task TheCatalogParameters_areBoundUnderTheDialectsBindNames()
+    {
+        await using var db = await SqliteBrowseFixture.CreateAsync();
+        var dialect = new ColonMarkerDialect();
+        await using var session = new SqlBrowseSession(db.Connection, dialect);
+
+        var tableNode = (await session.ExpandAsync(SchemaNodeId, CancellationToken.None))
+            .First(n => n.DisplayName == SqliteBrowseFixture.KeyValueTable);
+        var columns = await session.ExpandAsync(tableNode.NodeId, CancellationToken.None);
+
+        columns.ShouldContain(c => c.DisplayName == SqliteBrowseFixture.RealColumn);
+        dialect.BoundParameterNames.ShouldContain("schema");
+        dialect.BoundParameterNames.ShouldContain("table");
+        dialect.BoundParameterNames.ShouldNotContain(n => n.StartsWith(':'));
+        // Every catalog command went through the provider hook (Oracle's BindByName lives there).
+        dialect.ConfiguredCommands.ShouldBe(2);
+    }
 }
@@ -45,6 +45,13 @@
          — see its class docs.
        -->
        <Compile Include="..\ZB.MOM.WW.OtOpcUa.Driver.Sql.Tests\SqliteDialect.cs" Link="SqliteDialect.cs"/>
+        <!--
+          Linked for the same reason and on the same terms: ColonMarkerDialect is the control for
+          dialect-owned parameter naming (":schema" in the text, bare "schema" on the parameter — ODP.NET's
+          shape), and the browse session binds those names. It decorates SqliteDialect, which is already
+          linked above, so the pair travels together.
+        -->
+        <Compile Include="..\ZB.MOM.WW.OtOpcUa.Driver.Sql.Tests\ColonMarkerDialect.cs" Link="ColonMarkerDialect.cs"/>
    </ItemGroup>

 </Project>