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).
Pros
- 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)
Cons
- 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
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).
Pros
MySqlHelper) could move out of the main namespaceCons