Parameters should use the length of the underlying model column where available

[simonsabin]

Currently string and binary parameters are added without a length meaning you get multiple queries and plans causing bloat and is impossible to manage from a query store plan perspective as one, you ened up with 100s of queries with the same hash, but are different queries and also differing plans. Query is just varying by the length of the definition of the parameter. (See below)

The DBConnectionParam needs a length and the creation of params should use length where possible.

This could obtain the length of the underlaying model as it does to get the type of the underlying model column

data-api-builder/src/Core/Resolvers/BaseQueryStructure.cs

Line 120 in af09e10

public virtual string MakeDbConnectionParam(object? value, string? paramName = null)

[yorek]

Can you please create an issue so that it can be properly tracked and fixed?

[JerryNixon]

Hi, thanks for this new discussion.

Both of these enable the metadata placeholder to enable this fix.

1. The beginning of this has already been planned in this ⭐ [Enhancement]: Stored Procedure Parameters #2365
2. That is for stored procedures, for tables and views we have this [Enhancement]: Introduce Entity.Fields sub-property #2363

However, I believe a second approach could call into our in-memory metadata created when the engine starts up. The benefit of this is that developers cannot provide mismatched metadata, and we would not have to wait for the enhancements above.

In either case, we will track this here: #2628

@simonsabin Please feel free to add context to the issue to help us triage. I admit, I only 80% understand.

[JerryNixon]

I wonder if a quick fix might be to use (max).

[simonsabin]

MOved discussion to issue #2626