I have a bit of hard time to get a grip on type providers. I would like to get some feedback on the usefulness of type provider approach for following use case.
Quite unfortunately our telemetry API returns objects as List<Dictionary<string, object>>
. Dictionary
has strings for keys (meaning column names) and value can be any object (though, usually this is some value type in System namespace). Also, there is an method that returns Dictionary<string, Type>
collection that represents the schema (column name -> type binding). We usually use this data for ad-hoc/exploratory analysis and reporting.
F# with R type provider seems to be a great weapon for aforementioned analysis. Just accessing data by typing column names as strings and casting objects really stands in the way. I would like to create a type provider that will from given dictionary (connection string that creates the dictionary) create strong types. E.g. from
new List<Dictionary<string, object>>
{
new Dictionary<string, object> { {"a", 1}, {"b","data"}, {"c", DateTime.UtcNow } },
new Dictionary<string, object> { {"a", 3}, {"b","data2"}, {"c", DateTime.UtcNow } }
}
I would like to get
type MyObject
member a : int
member b : string
member c : DateTime
List<MyObject> ...
Is this an appropriate use of type providers? As I said I am quite new to the field so any feedback would be appreciated. Furthermore if you have any examples of similar problems I could use for quickly getting from the ground please share (Csv type provider seems to be good starting point).
If typed access to the telemetry API is useful, there are 2 easy approaches:
A Type Provider is particularly appropriate if:
With a Type Provider the API can be checked at a specific interval, e.g. each time an application is compiled. Type Providers can be lazy so that only code is generated for the data that is consumed, so if the data is large it would also be a more appropriate choice.
Michael Newton has a great introduction to writing Type Providers: Type Providers from the Ground Up