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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default namespace to MySqlConnector #824

bgrainger opened this issue May 28, 2020 · 4 comments

Change default namespace to MySqlConnector #824

bgrainger opened this issue May 28, 2020 · 4 comments


Copy link

This reopens #189.

Poll: Please vote 馃憤 or 馃憥 on this issue if you'd like to see this implemented (or not).

In the past, MySqlConnector was simply trying to become a replacement for MySQL Connector/NET, and cloning its API (down to the namespace) seemed like an easy way to displace it, by providing a simple upgrade path. But as the list of known Connector/NET bugs and edge cases has grown, MySqlConnector has chosen to become incompatible in an increasing number of ways. Thus it's much less true that a user can upgrade by just changing their NuGet package reference and none of their code.

Additionally, MySqlConnector is now pushing the API forward (async, batching, bulk copy, etc.) beyond what Connector/NET supports. It makes sense for these new features (that are "defined" by MySqlConnector) to be in their own namespace (instead of in a namespace where they might one day conflict with Connector/NET if it ever implemented those classes slightly differently).

Finally, while it's possible to use both MySqlConnector and MySql.Data in the same project, it's difficult and it impacts all consumers of that project: mikependon/RepoDB#375 (comment).


  • Dedicated namespace for all new MySqlConnector features
  • Makes the NuGet package name match the primary namespace
  • Legacy APIs (such as MySqlHelper) could move out of the main namespace
  • Easier to use both MySqlConnector and MySql.Data in the same project (possibly niche use case, but useful for benchmarking)
  • Easier to find API documentation for this library (e.g., with Google)
  • Makes it clear that "MySql.Data" is unrelated to this library (as that would no longer appear in the code)
  • Makes it clear which library is being used when a stack trace is posted (e.g., on Stack Overflow or a GitHub issue)


  • Breaking change for all current users
  • Harder to upgrade for new users
  • Effort required to update code, documentation, open PRs to important downstream projects
  • Less likely to capture new users by showing up in Google results for MySql.Data.MySqlClient
@bgrainger bgrainger pinned this issue Jun 1, 2020
Copy link

a user can upgrade by just changing their NuGet package reference and none of their code.

So long Mysql.Data, it was nice while it lasted.

Copy link

This library has proven its worth and the user will use it accordingly (even with Namespace change). If I am to weigh the PROS and CONS above, I would gladly like to choose the benefits of the PROS above. My use case of having an ORM that could abstract both library is quite unique (so for others), but it would help me a lot when it comes to maintainability, operation-wise and simplicity. The use-case of combining both libraries (i.e: MySql.Data and MySqlConnector) is a quite good use-case in which you do not limit the users to explicitly remove the other. I would suggest it will start from here unless Oracle decided to not coincide on this tool.

Copy link

My 2 cents in favor of this change:

  • This library has gained enough traction that nobody will stop using it because of this change
  • Most projects use some library like EF or Dapper in a way that the change would be restricted to a few places only
  • A search/replace can easily migrate a project to the new namespace

This is a change that should bump the version to 1.0 or even 2.0.

@bgrainger bgrainger added this to the 1.0 milestone Jun 5, 2020
Copy link


@bgrainger bgrainger unpinned this issue Jun 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants