Repodb: Request: Enable ExecuteQuery<T>

[nicko-franco]

Hi Sir, first of all, thank you for this wonderful ORM library. Just wanna request if you can support generic type binding for ExecuteQuery function. Currently it has dynamic and object return type, but it would be great if we can pass a generic return type as well instead of only concrete classes. Thanks and God bless!

[mikependon]

This is already supported, see the documentation here. Or, you can do the code below.

using (var connection = new SqlConnection(connectionString).EnsureOpen())
{
    var people = connection.ExecuteQuery<Person>("SELECT * FROM [dbo].[Person];");
}

In the link above, you can pass different sets and types of parameters. Just FYI.

[nicko-franco]

What I mean is to pass a generic type instead of a reference type as shown in your example.

So in this code snippet, what I want is to have something like:

return connection.ExecuteQuery(spName, CommandType.StoredProcedure);

[mikependon]

TBH, I am confused a little, so apology for that. :) Anyway, would not your code be working if you are to refactor it like below?

public IEnumerable<T> ExecuteQuery<T>(string spName) where T : new()
{
    using (var connection = new SqlConnection(connectionString).EnsureOpen())
    {
        return connection.ExecuteQuery<Person>(spName, CommandType.StoredProcedure);
    }
}

No need to do the redundant try-catch-finally statement here. It will be disposed on exception as you are wrapping it within a 'using' clause.

Or, please elaborate further. Thanks

[nicko-franco]

Actually I created this method to avoid repeatedly adding the sqlconnection stuff on all my data access classes. Like this:

So what I pass to ExecuteQuery is a generic type instead of the actual class. But I'm getting an error coz what it accepts is just reference type.

[mikependon]

Yes, that's correct. I overlooked that 'new()' thing. Thanks for the clarity.

[nicko-franco]

Thank you! And sorry for my unclear explanations :D

[mikependon]

I am actually trying to remove the 'Type Constraints' on this method and also to the other methods, rather than adding the 'new()' constraint. Will that affect your functionality?

Reason: I believe that in C#, that is okay, but in F#, it might fail as F#'s classes are immutable. Placing the 'new()' keyword may limit the usage of this library to F#. That's the reason as why I wrote a story #465 to support the F# case.

But, I am still on the middle of verifying the F#'s case.

[nicko-franco]

Removing the Type Constraints should be ok. I don't think it would break any functionalities that I have already implemented.

Maraming Salamat po!

[mikependon]

Thank you for verifying it. Will update you further on this ticket. Walang anuman!

[mikependon]

The impact of this request is huge. I am mid-way on my changes and upon looking towards based on the compiler's 'Search' resultsets, it will affect almost 90% of the classes in all solutions. I may never proceed with code changes for this request, I may be affecting the other users of the .NET community if I do so.

In short, I had reverted back the changes made locally.

I would humbly say, in your part, please limit the type parameter constraints to class and remove the new() parameter-less constructor requirement.

FYI: Entity Framework Core is doing the same as RepoDb.

[nicko-franco]

Hi Mike,
Thanks for your prompt response. I'll just think of a workaround for my code to avoid using generic types.
Maraming Salamat and more powers to RepoDb 👍

I'll close this issue now.