Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add fluent configuration with IDbConnection #499
This adds the ability to use the fluent config syntax with an existing connection, either using the default provider for the connection or providing a custom one:
var config = DatabaseConfiguration.Build() .UsingConnection(myDbConnection); var config = DatabaseConfiguration.Build() .UsingConnection(myDbConnection) .UsingProvider<MyCustomProvider>();
As part of this, I refactored the section of the
There's one thing I noticed but did not change. In the framework section of the code, if we're initializing from a connection string entry, we fallback to the SQL server provider if the connection string is missing the provider section. But in the netstandard section, if there's no provider and no provider name supplied in the config, we just throw an exception instead of falling back. Is this intentional? If not, I can add the fallback to the PR.
Likely an oversight. We should have the same default IMO.
Looking further at the various constructors, I found the following behavior for resolving providers.
The one that sticks out to me now is Non-fluent number 4. If we're asking the user to pass in an explicit name, we should make sure he does so and throw an exception if
Overall, this means that the ruleset is that we're lenient if we're delegating to a connection string entry that the user may not have control over, but stricter if we're asking the user to give us things directly. I think this makes good sense
With that in mind, my earlier comment about Fluent number 3 was wrong. I didn't see that the config setter disallows null/empty values for the provider name up front, which is good. The fluent constructor then throws if no provider name was set at all and throws if the given provider name can't be resolved, both of which are correct.
Please let me know what you think, and I'll amend the PR accordingly.
Edit 2/18/19: Clarified Fluent 1 and 3
referenced this pull request
Jan 9, 2019
I think you nailed it.
With that said, it should probably throw.
Happy to do another release when you say this PR is ready
Okay, I'm satisfied with this -- I have changed non-fluent constructor number 4 as detailed above, and I've walked through all the code to make sure my refactorings didn't break anything.
Note that this could be considered a breaking change, since currently if someone uses that constructor and passes in an empty or invalid string, they'll get the default provider -- and now they'll get an exception.
There's one other thing I noticed. For the fluent syntax,
Also, note that in .NET Standard you could apply both
Let me know if you'd like me to deal with this. Otherwise, we're good to go.
I think this should be ok. Yes, it's a breaking change, but it's not an obvious redefinition of use. I feel it's more about ensuring the correct usage is adhered to.
Yep go for it. I'm also happy to take this PR as-is if you wanted to sort that out at a later time