Result type for static param method was not added

[dmitry-a-morozov]

I'm trying to do what describe in readme document but does have example

      type DbPediaProvider<”A”>
                method Search<”B1”> (returns types depending on a search of DbPedia using string "B1")
                method Search<”B2”> (returns types depending on a search of DbPedia using string "B2")
                nested type SearchResults
                    nested type Search_B1_Results // use the mangled name provided for the method to create these types
                    nested type Search_B2_Results // use the mangled name provided for the method to create these types

I cloned your original repo and added one more method with static params usage example is here https://github.com/dmitry-a-morozov/SampleMethStaticParamProvider/blob/master/sample.fsx#L13 It's strongly typed property bag.

Result type is added here:

https://github.com/dmitry-a-morozov/SampleMethStaticParamProvider/blob/master/src/SampleMethStaticParamProvider/TypeProvider.fs#L60

But I still receive: System.Exception was unhandled by user code Message: An exception of type 'System.Exception' occurred in FSharp.Core.dll but was not handled in user code Additional information: type 'CreateBag,Properties=Name,Age"_Result' was not added as a member to a declaring type

[dmitry-a-morozov]

Let me know if my explanation of the issue is not clear or sufficient. Also I would like to add that though access to result type of possible SqlClient Execute method with static params seems like rare case it is essential for writing interfaces for abstract data access layer. Today with SqlCommandProvider it's done like following:

type GetAB  = SqlCommandProvider<"SELECT A = 1, B = 2", connStr>
type GetCD  = SqlCommandProvider<"SELECT C = 3, D = 4", connStr>

type IRepository = 
    abstract GetAB: seq<GetAB.Record>
    abstract GetCD: seq<GetCD.Record>

//real impl
type Repository() = 
    interface IRepository 
...

//for unit testing
let testRepo = {
    new IRepository with
        ...
}

Hopefully I can provide similar experience for methods with static params.

[dsyme]

I'm not yet reproing the error. I forked your repository, built the type provider then ran \codeplex\visualfsharp\forks\dsyme\cleanup\Debug\net40\bin\fsi.exe sample.fsx

and got:

In GetStaticParametersForMethod
In GetStaticParametersForMethod
In ApplyStaticArgumentsForMethod
In GetStaticParametersForMethod
In GetStaticParametersForMethod
In ApplyStaticArgumentsForMethod
In GetStaticParametersForMethod
In GetStaticParametersForMethod
In ApplyStaticArgumentsForMethod
In GetStaticParametersForMethod
In GetStaticParametersForMethod
In ApplyStaticArgumentsForMethod
In GetStaticParametersForMethod
In GetStaticParametersForMethod
In ApplyStaticArgumentsForMethod
1
2
3

without an error.

[dmitry-a-morozov]

True. I cannot reproduce it either. But more important that I don't see nested type "CreateBag,Properties=\"Name,Age\"_Result" .

[dsyme]

Does that mean things are working? :) Or not? thx

[dmitry-a-morozov]

It DOES NOT work.

[dsyme]

OK, could you update sample.fsx in your repo to reproduce the problem? Thanks

[dmitry-a-morozov]

Don, I realized that nested type "ExampleType.CreateBag,Properties="Name,Age"_Result" is accessible but doesn't show up in IntelliSense.
I pushed update to script.fsx that proves that compiler does right thing. https://github.com/dmitry-a-morozov/SampleMethStaticParamProvider/blob/master/sample.fsx#L19 Sorry for false negative. So, this is only intellisense issue

[dsyme]

OK, great. BTW I do wonder if using the special characters in the type name may cause problems later, you might want to strip them out when choosing the mangled name.

[dmitry-a-morozov]

Yep - it was "=" char. For SqlCommandProvider mangled name will include a whole SQL string which can be really long. A type alias can help but what shows up on right side will be really ugly. Maybe Execute method should accept optional static parameter that allows to provide explicit type alias. Also, a convention where result types added as nested under "...Result" feel ad-hoc and half-intuitive. But I understand that come up with something better is non-trivial if possible at all.