[rohkhann]

Stored procedure today, is trying to validate that number of params in config == number of params in sp definition. this makes it difficult for customer as they have to respecify all the parameters in the sp in the config again. Our validation should only ever fail in two scenarios:

1. The customer provides inputs in the config that dont match whats there in the stored proc.
2. The customer does not provide input in the query and there is no backing default in the config. (ideally if there was a default on the db stored proc we should have detected it but it seems very hard for sql). As a workaround, customer can just define that default in the config if they want.

Difficulties in determining whether a stored procedure parameter has default values:

1. Documented by microsoft -

https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-sql-modules-transact-sql?view=sql-server-ver16 2. There are some alternatives but they are flaky -https://copyprogramming.com/howto/get-default-value-of-stored-procedure-parameter

We can try the SQL DOM approach but the focus on this pr is to ensure that irrespective of whether there is or is not a default parameter customers can query their endpoint. If there is no query parameter provided and nothing specified in config we error out (even if for now they have a default defined in the db.)

[aaronburtle]

Changes look good, but I did not see a negative case to provide test coverage for the cases you mention in the description about validation failing in the config validation tests or in the sp builder tests. Can you double check if we have a test of this, and if not add an issue to track adding if not adding to this PR itself?

[Sean Leonard (seantleonard)]

Need tests to validate scenario that you are trying to accommodate.

• If input parameter in db schema has a default value and 1) none is supplied in request 2) no default value defined in runtime config -> what is the expected outcome?

What kind of test do you think could validate your failure case proposal:

The customer does not provide input in the query and there is no backing default in the config. (ideally if there was a default on the db stored proc we should have detected it but it seems very hard for sql). As a workaround, customer can just define that default in the config if they want.

[Aniruddh Munde (Aniruddh25)]

Need validation of at least the params that are specified in config,
nit: fix PR title to reflect its purpose.

[Ayush Agarwal (ayush3797)]

Ideally, I think these cases make sense to me:

1. The parameter does not have a default value specified in the stored proc definition and in the config:
   -> User needs to provide value for that param
2. The parameter does not have a default value specified in the SP definition but has a default value specified in the config:
   -> User does not need to provide value for the param and we will use the value from the config.
3. The parameter has a default value specified in the SP definition and in the config (do we want to allow this scenario?):
   -> User does not need to provide value for the param and we will use the value from the config.
4. The parameter has a default value specified in the SP definition but not in the config:
   -> User does not need to provide value for the param and we will use the value from the SP definition.

For doing this, we would need the metadata about whether a param has default value in the SP definition or not.

[Aniruddh Munde (Aniruddh25)]

Ideally, I think these cases make sense to me:

1. The parameter does not have a default value specified in the stored proc definition and in the config:
   -> User needs to provide value for that param
2. The parameter does not have a default value specified in the SP definition but has a default value specified in the config:
   -> User does not need to provide value for the param and we will use the value from the config.
3. The parameter has a default value specified in the SP definition and in the config (do we want to allow this scenario?):
   -> User does not need to provide value for the param and we will use the value from the config.
4. The parameter has a default value specified in the SP definition but not in the config:
   -> User does not need to provide value for the param and we will use the value from the SP definition.

For doing this, we would need the metadata about whether a param has default value in the SP definition or not.

Looks like the problem is SP definition cannot reliably provide us information whether the parameter has a default or not + we dont know what the value would be.

[Aniruddh Munde (Aniruddh25)]

LGTM. Thanks for fixing this! Would be nice if we can have a follow up for checking SP metadata using sys.sql_modules or OBJECT_DEFINITION as the docs suggest for finding if the parameter has default or not.

[Aniruddh Munde (Aniruddh25)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).

[Sean Leonard (seantleonard)]

Pending response to Abhishek's comment.

[azure-pipelines]

Azure Pipelines successfully started running 6 pipeline(s).