Merge | SqlConfigurableRetryLogicLoader #3246
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR merges the partial implementations of the SqlConfigurableRetryLogicLoader into a single common class while relocating the configuration interfaces into separate files.
- Consolidated platform-specific implementations into a unified loader class.
- Moved and separated configuration interfaces out of the manager file.
- Removed redundant .NET Core and .NET Framework specific files.
Reviewed Changes
Copilot reviewed 7 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| ISqlConfigurableRetryConnectionSection.cs | Adds interface for connection retry configuration. |
| IAppContextSwitchOverridesSection.cs | Adds interface for AppContext switch overrides. |
| ISqlConfigurableRetryCommandSection.cs | Adds interface for command retry configuration. |
| SqlConfigurableRetryLogicLoader.cs | Consolidates loader logic and implements new assembly resolution and type loading. |
| SqlConfigurableRetryLogicManager.cs | Removes duplicated interface definitions. |
| SqlConfigurableRetryLogicManager.NetCoreApp.cs | Removed redundant .NET Core-specific loader implementation. |
| SqlConfigurableRetryLogicManager.LoadType.cs | Removed redundant .NET Framework-specific loader implementation. |
Files not reviewed (2)
- src/Microsoft.Data.SqlClient/netcore/src/Microsoft.Data.SqlClient.csproj: Language not supported
- src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj: Language not supported
Comments suppressed due to low confidence (2)
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/Reliability/SqlConfigurableRetryLogicLoader.cs:23
- The removal of the 'partial' keyword consolidates the class into a single file. Please verify that no essential implementations from other partial class definitions are omitted.
internal sealed class SqlConfigurableRetryLogicLoader
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/Reliability/SqlConfigurableRetryLogicLoader.cs:400
- [nitpick] Consider using AppContext.BaseDirectory instead of Environment.CurrentDirectory in MakeFullPath to ensure a more reliable base path for assembly resolution.
string fullPath = Path.Combine(directory, assemblyName);
| namespace Microsoft.Data.SqlClient | ||
| { | ||
| /// <summary> | ||
| /// Configurable retry logic loader | ||
| /// This class shouldn't throw exceptions; | ||
| /// All exceptions should be handled internally and logged with Event Source. | ||
| /// </summary> | ||
| internal sealed partial class SqlConfigurableRetryLogicLoader | ||
| internal sealed class SqlConfigurableRetryLogicLoader |
There was a problem hiding this comment.
The more I see partial classes, the more I dislike them. Maybe they're just misused a lot in this codebase, but I find them so confusing and troublesome.
There was a problem hiding this comment.
I think they can be very useful, but they need to be sensibly used. I think partial classes, multiple classes in a single file, and filenames that don't correspond to the name of the class make this codebase more difficult to navigate and work on. It's something I want to incrementally resolve as I merge the projects.
In prior projects, I've used partial classes fairly successfully to split classes into logical divisions. Eg, writing an Antlr parser required a single class to handle all the nodes in the syntax tree, so having multiple partial classes to handle logical groupings of node handlers was a necessity. In this project, we have some classes that are so large (my) IDE refuses to do inspection or autocomplete on it (eg, TdsParser). If we have any hope of working on it, we'll likely need to split these up either into multiple classes or into partials.
Anyways ... I digress.
There was a problem hiding this comment.
From the docs here, the first 'desirable' example is questionable (If you need 2 people in the same file at the same time, maybe you have bigger problems?), and the other 2 examples relate to code generation. I get the feeling partials were added to make development of other MS frameworks easier.
Another somewhat interesting read is here: https://stackoverflow.com/questions/3601901/when-is-it-appropriate-to-use-c-sharp-partial-classes
IMO, if your class is "too big" for a single file, then you need to re-design your class. Sometimes artifically splitting up responsibilities is for the best, even if naturally they're all the domain of a single encapsulation.
OTOH, partial members might be useful for reference packages. Perhaps we declare everything as partial in our ref assembly, and don't provide any definitions. Would that eliminate the need for the "throw" pattern? Food for thought.
There was a problem hiding this comment.
@paulmedynski the first desirable sounds more like a holdover from the days of centralized source control (which Microsoft has much history) where having files checked out by multiple people isn't really feasible. I think if you can't comfortably have two engineers in the same file at the same time, you've got bigger problems :)
I don't really subscribe to the "if your class/method is too big you're doing it wrong" school of thought. I think sometimes it makes sense to artificially split things up, sometimes it doesn't. But I see it more of an artform. I'm sure you'll correct me if you think my PRs are bad :P
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3246 +/- ##
==========================================
+ Coverage 72.69% 72.76% +0.06%
==========================================
Files 303 298 -5
Lines 59718 59612 -106
==========================================
- Hits 43414 43377 -37
+ Misses 16304 16235 -69
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Description: Here is the latest merge PR to get us to a single project. This edition brings the netcore SqlConfigurableRetryLogicManager.NetCoreApp.cs and the netfx SqlConfigurableRetryLogicManager.LoadType.cs files into the common project SqlConfigurableRetryLogicLoader class. These files actually contained partial classes of the *Loader class and provided separate implementations of the LoadType functionality.
I also separated interfaces from SqlConfigurableRetryLogicLoader that should be in their own files. Lastly, I started getting carried with stylistic cleanup of the class, but stopped before it went too crazy. I have a follow up PR with those cleanup changes queued up for after this PR.
Testing: Project still builds, no functional changes.