-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CommandType support to SqlProgram #42
Comments
Something to consider when we add text execution is validation. This can be achieved by parsing the T-SQL first to ensure it is actually valid SQL, but then we would need to validate the objects referenced and any parameters it contains. We should utilise sp-describe-undeclared-parameters-transact-sql as this reports any syntax errors, along with any missing (undeclared) parameters. This would need to be executed against the database upon SqlProgram Validation for Example usage: EXEC sp_describe_undeclared_parameters
@tsql = N'SELECT object_id, name, type_desc FROM sys.Indexes;'
Output:
Nothing Invalid SQL: EXEC sp_describe_undeclared_parameters
@tsql = N'SELECT object_id, name, type_desc FROM sys.InvalidTable;'
Output:
Msg 208, Level 16, State 1, Line 23
Invalid object name 'sys.InvalidTable'.
Msg 11501, Level 16, State 2, Line 23
The batch could not be analyzed because of compile errors. Declared Parameter: EXEC sp_describe_undeclared_parameters
@tsql = N'SELECT object_id, name, type_desc FROM sys.Indexes WHERE name = @Name;',
@params = N'@Name nvarchar(128)'
Output:
Nothing Undeclared Parameter: EXEC sp_describe_undeclared_parameters
@tsql = N'SELECT object_id, name, type_desc FROM sys.Indexes WHERE name = @Name;' Output (partial):
|
This is really useful, however, as we can't guarantee to have all scripts available once at startup, then the overhead of round-tripping a validation step to the DB is probably not viable. In reality, the main thing we need to find are Identifiers, for disambiguation when combining batches (in #45), even better would be if we could figure out automatically what Identifiers are correctly initialised or specified. However, for now, we can validate that supplied parameters are used/referenced within a script, and potentially rename them when creating batches. |
- If a SqlProgram program is created without specifying the text and type, the name will be used as the text and the type will be StoredProcedure; this is the old behaviour - New overloads all all the Create/GetSqlProgram methods allow specifying the Text and Type of the program. - New attributes added to the <program /> configuration element, in addition to the existing mapTo attribute for mapping to a procedure, to allow a program to be mapped to raw SQL text or a table. - The configuration overrides any text specified in code. - Added a new SqlParameterInfo type to replace usages of KeyValuePair<string, Type> when creating a SqlProgram. - Overloads of the methods that took parameter names as parameters, now take SqlParameterInfo instead. Strings can implicitly cast to this type. - SqlParameterInfo also allows the SQL type of the parameter to be specified. For sprocs, it validates the type is the same, for Text, it sets the type instead of it being inferred. Parameters are not allowed for table programs
SqlProgram needs to be enhanced to support more command types than Stored Procedures. In particular, we should support
CommandType.Text
to allow execution of dynamic, parameterized scripts. At the same time, we might considerCommandType.TableDirect
, though it is not a core driver for this enhancement.The text was updated successfully, but these errors were encountered: