Override ToString() for generated ResultType.Record.

[fsprojects]

Override ToString() for generated ResultType.Record.

[dmitry-a-morozov]

More investigation required. It turned that ToString cannot be overridden for generated types. Confirmed with @v2_matveev. I'm not sure but I think it's limitation of provided types. StructuredFormatDisplayAttribute is not supported either.

[v2m]

You mean "cannot be overridden for erased types?"

[dmitry-a-morozov]

Right.

[dmitry-a-morozov]

The issue cannot be addressed for erased types. Only for generated.

The solution is to have the erased type's representation implement the ToString override. The representation should store enough schema inrformations to implement the ToString logic exactly as if you had provided a bespoke ToString override through generated code.

Similar techniques can work for debugging etc., i.e. provided a debugging display on the erased type representation http://bit.ly/HYG7F5

[dmitry-a-morozov]

@dsyme I tried ToString() override - it didn't work. I confirmed it with @v2m. He also said DebuggerDisplayAttribute won't work either. After some thinking I understood why.

Did you do the override on the representation type (i.e. which is not a provided type, but a type you've defined in your runtime library?)

[dmitry-a-morozov]

Nope. I don't have representational type because I don't need one. Provided type erased to standard System.Data.SqlClient.SqlCommand. I got your point. I'll think about it. Maybe a good idea.

[dmitry-a-morozov]

@dsyme Sorry, I misunderstood your question. The source of problem was provided erased type that we use to represent rows as record with properties. It erased to array which is of course very efficient. Confusion was around a way option<_>.None value printed as .

[[|Some "rowID"; Some "NO"; Some "int"; null; Some 10uy|];
[|Some "districtID"; Some "NO"; Some "int"; null; Some 10uy|];
[|Some "districtName"; Some "NO"; Some "nvarchar"; Some 150; null|]; ...

So, it's not that bad. I thought I can fix it if there is an easy way to override ToString for provided type. Otherwise it's not worth an effort to create base run-time type only to override "ToString". Plus overhead comparing to arrays.

Do you have any runtime component at all? thx

[dmitry-a-morozov]

Very little. Only something to represent typed DataTable
http://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTypeProvider/blob/master/src/SqlCommandTypeProvider/DataTable.fs

because I could not use
http://msdn.microsoft.com/en-us/library/bb358258.aspx
with erased types

Also, some extensions to types from SqlClient namespace.
http://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTypeProvider/blob/master/src/SqlCommandTypeProvider/SqlClient.Extensions.fs

[dmitry-a-morozov]

@dsyme It would be nice to have short post from you or other expert (Keith, Tomas or Vladimir) on structuring TP projects. Some sort of guidelines. Because it's bit confusing.

1. Should TP projects always be split into run-time/design-time. XMR provider for example is one piece. What are clear advantages of having 2 parts?
2. If broken into 2 parts should run-time refer to design-time (WMI provider) or opposite (like most other providers).
3. There is some trickery around loading either design-time lib (I believe Keiths does it in WMI provider via saving MethodInfo refs) or run-time (via ResolveAssembly event).

Thanks.

[ovatsus]

1. I'd say that if you don't need to support multiple .NET profiles, don't botther spliting into 2 parts, the complexity will increase immensely, and the only upside you'll get is a slightly lighter runtime dll.
2. Referencing other assemblies in a type provider is troublesome (see the recent discussions on twitter about powershell scripts in the R and Azure type providers). In both Fsharpx and FSharp.Data type providers, the design time assembly simply reincludes all the files from the runtime assembly, and there is no assembly reference.