Skip to content
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

User Defined Functions/ Table Valued Functions #43

Open
sydsutton opened this issue Dec 8, 2022 · 12 comments
Open

User Defined Functions/ Table Valued Functions #43

sydsutton opened this issue Dec 8, 2022 · 12 comments

Comments

@sydsutton
Copy link

Hello,

I was wondering if you would be open to the idea of either adding and/or receiving a PR for User Defined Functions and Table Valued Functions? I use MS SQL Server, and would very much like to use SQL Hydra in conjunction with UDF's/TVF's. I might know someone who can help with the PR if that's the route you decide to go.

Thanks so much.

@JordanMarr
Copy link
Owner

JordanMarr commented Dec 8, 2022

I assume this feature would exist within the SqlHydra.Query library. Would it involve type generation?
Can you give a code example of how you imagine it would be used?

@sydsutton
Copy link
Author

Yes, it would involve type generation. And I will get back to you as soon as possible with a code example.

@sydsutton
Copy link
Author

This is my current code, just with the table that I'm referencing taking a parameter instead of taking no parameter. In MS SQL Server, the table being called would take the "calculation" that was passed in and do some math based on the calculation.
image

@JordanMarr
Copy link
Owner

What kind of support does Microsoft.Data.SqlClient provide for getting metadata on table valued functions?

@JordanMarr
Copy link
Owner

While GetSchema / Procedures does list UDFs, including a custom table function that I made, GetSchema / Columns doesn't list any of the returned columns.

So there would need to be a metadata query that returns:

  • The table valued function inputs (names, types)
  • The table valued function output columns (names, types)

@sydsutton
Copy link
Author

sydsutton commented Dec 9, 2022

-- To get Table Functions
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION' AND DATA_TYPE = 'TABLE'

-- To get Scalar functions, same as above except filter out DATA_TYPE 'TABLE'
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION' AND DATA_TYPE <> 'TABLE'

-- To get output columns
SELECT * FROM INFORMATION_SCHEMA.ROUTINE_COLUMNS -- Join on `TABLE_SCHEMA` and `TABLE_NAME`

-- To get input parameters
SELECT * FROM INFORMATION_SCHEMA.PARAMETERS -- Join on `SPECIFIC_SCHEMA` and `SPECIFIC_NAME`

@JordanMarr
Copy link
Owner

This seems doable. However, there is some refactoring in process that needs to be completed before this can be started.

@sydsutton
Copy link
Author

Ok, that sounds good. Thank you for being open to the idea. Please let me know if there's anything else you need from me.

@RJSonnenberg
Copy link

RJSonnenberg commented Feb 8, 2024

@JordanMarr Is there any movement on this? Our team has run into an issue where we have to run both table and scalar functions and get the results. Would this solution be able to support scalar functions in addition to the table functions?

@JordanMarr
Copy link
Owner

JordanMarr commented Feb 9, 2024

It would be a nice feature to have for sure, but it’s not something I need and therefore no movement.
Currently, vanilla ado.net would probably be the easiest way to do it (unless you have a ton of functions, in which case I could understand why you would want this as a feature).

@sydsutton
Copy link
Author

@RJSonnenberg I think I ended up using Dapper for this particular issue. I can send you more specifics in the morning if you need them.

@JordanMarr
Copy link
Owner

This feature looks like it could be challenging to implement because:

  • different providers will likely have different queries to pull function names, inputs and outputs
  • there are different kinds of functions, and some of them return custom types which is another feature that isn’t supported
  • obviously the code generation piece would be difficult
  • The Query library would need to somehow know that the generated functions were usable in the queries and that they should be spliced in (presumably by inspecting their path name)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants