Generated types

[rojepp]

Just to get a conversation started..

It would be nice if types could be generated instead of erased. This would enable use from C#. I have never made a generated type, so I have no idea how much work would be involved.

[dmitry-a-morozov]

I do have required experience :)
https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wiki/INotifyPropertyChanged-Type-Provider#round-3---generated-types--custom-runtime-base-class

[dmitry-a-morozov]

@rojepp While thinking about implementation for this feature I realized that to be usable from C# Task<'T> should be return for async ops instead of Async<'T>, right?

[rojepp]

Having Generated types would make it usable from C#, but you are right, the Async would not be comfortable. :)
Use of F# Option also would not be idiomatic from C#, but usable.
Once we have generated types, we could always add ExecuteAsync (while still keeping the AsyncExecute we have today).

I've been thinking that Execute/AsyncExecute do too much, in that they manage the connection. This means that Execute/AsyncExecute can not be part of a transaction. Can you think of a nice design around this, while still keeping comfortable Execute/AsyncExecute?

[dmitry-a-morozov]

@rojepp In current implementation command can be part of transaction via auto-enlist feature http://stackoverflow.com/questions/2884863/under-what-circumstances-is-an-sqlconnection-automatically-enlisted-in-an-ambien
but it's certainly not the best way. To do it right, we have to follow SqlCommand design and accept SqlTransaction as optional param to ctor.

[rojepp]

Enlisting/Opting out via Transaction scopes is fine by me. I just didn't realize it would work when closing the connection explicitly. Thanks.

[dmitry-a-morozov]

Transaction support something that might be necessary. Let's keep it open .

[rojepp]

I agree. But I also think most modern code (the kind of code that would consider using this TP) would probably use TransactionScopes, so it's not a priority to me.

[rojepp]

Small update: I've been able to remove a few obstacles here, but I'm stumbling upon this: async { } blocks doesn't seem to be supported when Type Provider is generated. They create an unbound Var in the Expr tree, named 'builder@' of type AsyncBuilder, which I can't seem to give a proper value. I'll let you know if I find anything else.

[dmitry-a-morozov]

At this point I'm convinced that C# friendly provider should be separated type. Differences are too many to have it in same type. We'll probably can archive some code reuse with erased types version.

[rojepp]

Having a generated type is still useful even in F#, if it can be done without complicating things too much:

• Should be less time to get the first result (I haven't measured, but it seems pretty slow to me)
• We can inspect the generated code in ILSpy
• It can be reflected
• Can override ToString (Override ToString() for generated ResultType.Record. #26)

I'd like to leave this open until we know more.

[dmitry-a-morozov]

@rojepp I know you're working on generated types version. As far as understand driving force is make usable from C#. I'm not sure what you meant by "Should be less time to get the first result" because in general erased types TPs are faster at run-time than generated types TP.
To make sure we're same page I think following requirements should be met for generated types TP:

1. async method should named ExecuteAsync to follow C# convention
2. ExecuteAsync has to return Task<'T> not Async<'T>. And Task (not Task) for non-query commands.
3. ExecuteAsync method should have overload that accept CancellationToken because async cancellations done differently on C# style async.
4. Result.Tuples doesn't make any sense on C# version because it will be useless without pattern matching
5. Nullable columns should be mapped to Nullable<_> for value types only instead of option

Unless all above done it cannot be presented to c# community because it will cause negative reaction.

[rojepp]

I agree on all of these points. Getting it running at all (while avoiding a
complete rewrite) is a first step.
If I get it working (big if, at the moment) I'm thinking we should have a
flag determine the api-style.
Would be cool to get it working cleanly, as a way to help drive F#
adoption. I ILSpy'd the output from erased, and I was wrong. They should be
equally fast.

[jackfoxy]

IMHO it's a mistake to work on making SqlCommandTypeProvider C# friendly, or even C# usable. Concentrate instead on making it the best possible tool for F#. Making it C# usable will do nothing to encourage C# programmers to learn F#. Seeing how well this works in F# will do more to encourage F# adoption. The SQL tools available in C# are too evolved and too entrenched.

[dmitry-a-morozov]

That's why I would to hear some guidelines from gurus like Don Syme and Tomas Petricek.
The following questions need some answers:

1. Do we want to develop generated types providers only to attract C# community? @jackfoxy is right, it can be deceptive.
2. If answer is "yes" to 1 then what's recommended development strategy: one gen types only provider, two separate providers or one that configurable to support both erased/gen and 2 different idiomatic styles? All options have problems.

[jackfoxy]

I am a couple of minor releases behind, but I applied SqlCommandTypeProvider to a real world problem on a real world legacy production SQL DB, and it my opinion it is by far the best solution for reading SQL Server in the F# world (haven't tried writing yet, but that is next). I recognize some minor limitations, and in the unlikely event I ran into them I could always fall back on @mausch's very usable solution. I am very interested in seeing this project progress for the F# community.

C# compatibility is attempting too much for no good purpose.

[rojepp]

I'm thinking it's a way to get people to hit that 'New F# project' button,
because they have to. Once there, it takes care of itself. @dsyme ?

[ghost]

It is, but you could do a C#-compatible fork, couldn't you? Using generated types has advantages but might prevent the TP becoming stable quickly and addressing other usability concerns.

BTW I love how simple this TP is!

Just my 2c worth, I haven't thought about this much or used the TP. Don't take my comments too seriously :)

[dmitry-a-morozov]

@rojepp I will take the liberty to interpret @dsyme's comment. Instead the separate fork I would rather have separate type provider. Some code reuse can be archived internally. Deep down I think @jackfoxy is right - we won't be able to convert C# dev to F# by providing gen types versions of TPs. That said, I'm still willing to give it a shot. But i suggest first to stabilize API and release erased types version 1.0. Once we're satisfied with design and quality we'll work on gen. types version.

[jackfoxy]

Well some TPs would prove useful to C# devs, I think not one for SQL Server, however.

[rojepp]

@jackfoxy Where do you get that idea from? I've shown this TP to a few C#-minded colleagues, and all were amazed, and the first question was, 'Can this be used from C#'? Perfect for LOB apps.

[jackfoxy]

I had the opposite reaction, “if it’s not entity framework, I’m not interested”.

Anyway,from my perspective it’s better to get the project rock-solid in F# and documented first before worrying about C# interop.

Sent from Surface

From: Robert Jeppesen
Sent: ‎Saturday‎, ‎November‎ ‎16‎, ‎2013 ‎10‎:‎57‎ ‎PM
To: dmitry-a-morozov/FSharp.Data.SqlCommandTypeProvider
Cc: Jack Fox

@jackfoxy Where do you get that idea from? I've shown this TP to a few C#-minded colleagues, and all were amazed, and the first question was, 'Can this be used from C#'? Perfect for LOB apps.

—
Reply to this email directly or view it on GitHub.

[rojepp]

There are lots of devs who wouldn't touch EF with a ten foot pole. Myself included. ;)