LogSqlDepenceny: what is the use of the 'tablename' parameter

[fgheysels]

The LogSqlDepenceny method takes a tableName parameter. I wonder what the use of this parameter is.
I'd say you have a dependency on a database that exists on a server, so the datasource/servername and database parameters make sense, but the table-name is imho an implementation detail in the database. I don't think we should use that in dependency tracking ?
Moreover, what are you going to pass to that parameter if you execute a number of queries that target multiple tables (you know, with joins etc..).

I'd say we need to remove that parameter. Any thougts @gverstraete @stijnmoreels

[stijnmoreels]

Hmm, the tableName is already there from the very beginning. On both overloads. I understand what you're saying. It only feels that we have a lot of these implementation details in our dependency tracking. The Azure Key Vault name and secret name, for example, are also tracked. I'm no expert in telemetry, but this feels like rather important info when tracking dependencies.

What we can do, is maybe make this parameter optional (not making it by default null, only not guarding against it anymore). That way, it can be left blank. Also, this parameter is free to be whatever the consumer wants. It can be customer & order for example, when a multi-table statement is run. Removing it, would case some friction with other overloads and we probably will have to create some different signatures to remove any conflicts. Not sure if this is worth it. Again, not a telemetry expert.

[fgheysels]

I agree that we can make the param optional by not guarding it anymore, or maybe we should rename it ?
Maybe it is possible for instance to use it to pass in the SQL query one is executing.

[stijnmoreels]

Ah, yes, a pseudo SQL query/command is maybe a good one for this. Maybe in a different overload. Both can be considering, right. Not guarding + overload with pseudo SQL query/command.

[fgheysels]

I'm not talking about a pseudo one, but the one that is really executing :) At last, the consumer of the lib can do whatever he wants.
(I assume that the tableName parameter gets logged as a context property in the dependency.

[gverstraete]

My call on this is pretty short.. If I read this here it is mandatory, I can agree to make it optional, but let's not make a breaking change out of this.

[fgheysels]

I'd suggest to rename the tableName parameter to something more generic.
However, I'm also interested in how / when this dependency-tracking is used. I'd assume that dependency tracking to SQL Server is done 'out of the box' ? Or am i wrong ?

[gverstraete]

At the time this library has been written, definitely not! For now, I would need to check

[fgheysels]

I think we agree that tableName should not be mandatory (not be guarded against) and that we can rename it so that it has a more generic name, something like sqlCommand or sqlCommandInfo ?

[fgheysels]

Created an issue: #286