-
Notifications
You must be signed in to change notification settings - Fork 19
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
Split the block into separate packages for each database #39
Comments
As I see it, the root problem is at This allows users to create a database provider for SQL Server or Oracle even without mapping a provider in the configuration, just by providing a connection string name. DAAB will read the We can see how this works in the Data.SqlCe.Tests.VSTS project. If you look at the So if we split the Data project to separate projects and assemblies for each database provider, we'll have to require users to map their provider name to database provider in configuration. |
This is a major change, and I plan to make several PRs for it. But if I merge partial changes to master, we won't be able to make new releases (or it will become difficult). So I suggest I branch from master, update my fork, and work on it on that branch in my fork. Then, I'll make a PR from the branch on my fork to the branch in this fork. What do you think? |
register OracleDatabase in configuration. EnterpriseLibrary#39
register data provider for .net core. EnterpriseLibrary#39
* move OracleDatabase and related code to a Data.Oracle project. #39 * remove unused usings, reference to Oracle in XML comments #39 * move types n OracleConfigurationExtension.cs to their own file #39 * add reference to Data.Oracle to TestSupport project, so it compiles. #39 * fix namespace #39 * use nameof() #39 * fix config section assembly name register OracleDatabase in configuration. #39 * fix package versioning #39 * add a mapping of OracleDatabase to synthetic configuration. #39 * add configuration of an oracle database provider #39 * register OracleDatabase provider; fix assembly name for section handler. register data provider for .net core. #39 * map oracle database provider #39 * add the Data.Oracle project and fix usings #39 * add oracle database provider configuration * add oracle database provider registration #39 * remove reference to oracle nuget package #39 * move common code to extension method #39
add reference to System.Data.Odbc NuGet package add links to GlobalAssemblyInfo.cs and DataAccess.licenseheader include Nuget\readme.txt fix Data.Odbc namespace add missing Apache 2.0 license boilerplate on original code. #39
Add ODBC database provider to test config make OdbcDatabaseData constructor publc #39
replace <devdoc> with <summary> remove trailing whitespace. #39
As you can see from the commits above, I ended up creating an OleDbDatabase and OdbcDatabase, in two separate projects/packages. This is because each of them carries it's own package dependency, depending on the target framework. So now we have:
|
embed icon in package instead of pulling it from another package on nuget.org #39
add Enterprise Library Open Source Project as copyright owner #39
This is essentially done. support for Microsoft.Data.SqlClient will be done at #38 . |
Is your feature request related to a problem? Please describe.
Today there is one big package that supports SQL Server, Oracle, and SqlCE. There is no reason people using SQL Server will take a dependency on packages supporting Oracle, and vice-versa.
Describe the solution you'd like
We should split the package to several packages, so that:
The text was updated successfully, but these errors were encountered: