New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make connection param mandatory when literal conn str used at design time #195

dmitry-a-morozov opened this Issue Mar 23, 2016 · 1 comment


None yet
2 participants
Copy link

dmitry-a-morozov commented Mar 23, 2016

At the moment there are 2 ctors on generated command types:

  1. connection: string * ?commandTimeout: int -> 'Command.
  2. ?connection: SqlConnection * ?transaction: SqlTransaction * ?commandTimeout: int -> 'Command.

The fact that all parameters are optional for the second constructor allows to create instance of command without providing any parameters. In that case connection string provided at design time reused at run-time. This makes sense for config file based configuration e.g.

type Get42 = <"SELECT 42", "name=AdventureWorks">

But can lead to unintended mistakes when literal used at design time

type Get42 = <"SELECT 42", "Server=.;Database=AdventureWorks;Trusted_Connection=yes">

So proposal is to make connection instance mandatory parameter in second ctor if connection string literal provided at design time. Type signature of second ctor should be :
`connection: SqlConnection * ?transaction: SqlTransaction * ?commandTimeout: int ->

Based on feedback from @dsevastianov.

ntr added a commit that referenced this issue Apr 3, 2016

@ntr ntr assigned dmitry-a-morozov and unassigned ntr Apr 3, 2016

ntr added a commit that referenced this issue Apr 10, 2016

dmitry-a-morozov added a commit that referenced this issue Apr 11, 2016

#195 - Make connection parameter mandatory when literal connection st…
…ring used at design time (#209)

* #195 - fixed

* small improvment

This comment has been minimized.

Copy link
Member Author

dmitry-a-morozov commented May 16, 2016

Fixed in v1.8.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment