Skip to content
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

Closed
dmitry-a-morozov opened this issue Mar 23, 2016 · 1 comment
Assignees

Comments

@dmitry-a-morozov
Copy link
Member

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 pushed a commit that referenced this issue Apr 11, 2016
…ring used at design time (#209)

* #195 - fixed

* small improvment
@dmitry-a-morozov
Copy link
Member Author

Fixed in v1.8.2

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

No branches or pull requests

2 participants