Pomelo.entityframeworkcore.mysql: Close this repository or keep maintaining?

[yukozh]

Since oracle has released the mysql for ef core provider(https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore/7.0.4-IR-19). Should we keep maintain this repository?

Viewpoint 1
Stop this, we can concentrate on other libs such as MyCat(Will inherit all features from Pomelo.EntityFrameworkCore.MySql).

Viewpoint 2
Keep this, we will support more features like json field querying.

I would like to know who is using our library, and which library you will choose in future(official version or pomelo version)

[717009629]

Whatever decision DaShen made I would support you .

[yukozh]

@ErikEJ @YandyZaldivar @greghroberts @caleblloyd and any others who interested in this lib.

[seayxu]

:+1: Go on,support you to do this,and hope more features for developers.

[myloveCc]

Thank you for your efforts, this is a very good framework.

[applenele]

I hope to keep this one.

This one is an open source project, but the official one is not(At least the 7.0.4 version is not).

Besides, there were many features has been supported in Pomelo like json supports.

In the past, oracle didn't make mysql provider for ef(ef6) works well. For example, it will throw an exception(Specified key was too long; max key length is 767 bytes) while creating the database.

[LonghronShen]

I want to keep this one because it's a free implementation so that we can deeply modify it when needed (for example, something modification to fit for integration of Chinese style technology stack...)
All in all, thank you for your hard work! It's excellent!

[ErikEJ]

Agree to leave open as an oss alternative to the official provider

[caleblloyd]

This library is great but I understand it must be lots of work to maintain. Oracle's may be open source, but it is not developed in the open.

I like that Pomelo is developed in the open, but if it is too much maintenance effort I will switch to Oracle. Thanks for all of your hard work!

[dNetGuru]

This is a personal choice. Surely this is a lot of work to maintain (and I wish I had found out about this project earlier before I started writing my own).

I know I'll be switching to Oracle's implementation BUT that does not hold true for everyone. Oracle is not very good at maintaining its open source projects and they are usually not developed in the open just released as open source! They are slacking with Java's development and angered the MySQL community enough for the main contributors to leave and start MariaDB (a fork of MySQL).

I'd suggest shifting your support towards MariaDB (it's not different at all at the moment but might diverge in the near future). This way MariaDB will have its own .Net Connector /w EF support.
I'm sure MariaDB folks would appreciate it.

[yukozh]

@dNetGuru, thanks for your suggestion. I agree with your viewpoint, and I'd love to contribute to MariaDB, but are you a member of MariaDB?, or can you recommend my project to MariaDB team?

/cc @vuvova, @nirbhayc, @janlindstrom, @9EOR9

[dNetGuru]

@Kagamine I am not a member of MariaDB however I contribute when I can. They are on GitHub and there is currently no connector for .Net

You can see their repos here: https://github.com/MariaDB and connectors on https://mariadb.com/products/connectors-plugins.

I think you should talk to 9EOR9 about connectors.

PS. I tried using the Oracle's connector and it just seems like it barely works at the moment!

[JaymzZh]

Just go on, it's a good job.

[matthewjcooper]

To be honest, this project has been working great for me and would love to see it keep going.

[greghroberts]

My "two cents":

Official connector has many problems (some already mentioned):

• Non-friendly license GPL
• Open source, but not open development. Oracle is way behind the times here.
• Limited async support (unless that changed in this release)

My suggestion is to pivot this project to be the EF Core provider for something like https://github.com/bgrainger/MySqlConnector, which is a true MIT licensed MySql/MariaDB connector (built from scratch). Focus on better features around JSON/Enums/Etc and performance. People will switch and support this project if this is the faster and more extensive version.

Another concern with this project, is that the current dependency, Pomelo.MySql.Data, is mostly a rip of the Oracle version and is likely in violation of their license. You can't just take their code and change the license :)

Moving to support MySqlConnector will give a real alternative and allow the community to build up a much stronger implementation than whatever Oracle dumps out. It also has the groundwork for better async support and is a much simpler/cleaner implementation from what I've seen.

Regarding MariaDB, it was my experience that the goal of that project is to be a drop-in replacement, and shouldn't really require a dedicated provider. I could be missing something, but I'd prefer a better provider that supports both vs one that only works with MariaDB for some reason.

[yukozh]

@greghroberts I want to know a bit more about @bgrainger 's works. Was it a full implementation of ADO.NET？

To @bgrainger, Would you like to cooperate this works together?

[csurn]

I want to say thank you for this awesome libirary.It really help me a lot.Just keep it.

[YandyZaldivar]

I support the idea of focusing in MariaDB and switch to something like https://github.com/bgrainger/MySqlConnector. Try to join forces with MariaDB team, I would certainly migrate to MariaDB having an EF provider like this. Thanks a lot for your quick answer and fixes to my issues.

[bgrainger]

I think our projects could be complementary. I have no plans to develop EF support in MySqlConnector (it's not a framework I use nor know much about), so it'd be good to have a library that does implement that and is known to work well with MySqlConnector.

I don't know yet if enough of ADO.NET is implemented in MySqlConnector to support your library; it would be interesting to change Pomelo.EntityFrameworkCore.MySql.Tests to use MySqlConnector and see if/where it fails.

[DMW007]

I worked with the full ASP.NET MVC Stack before for years and ran into problems yet using the official MySQL Connector. Its a shame that we need years after the release workarounds for common use-cases like database-migrations.

I'm loving .NET as a very good framework, but I also like open source for security, transparenty and the posibility of customizations/diversity with forks. For those reasons, I'm very happy to start with .NET Core, because my favourite language/framework is not a contradiction to open source any more.

And I also love Pomelo.EntityFrameworkCore.MySql: It took me minutes, not hours included some headaches for using EFCore with MySQL. And no dirty workarounds. Together with the open source concept, this seems like the perfect MySQL provider for me on EF.

I wouldn't like to experimentate with MySQL's provider for EF - What can he make better? Closed source? Messing with issues Oracle wouldn't fix? Strange errors where you have to spend hours guessing about 4 corners where the real problem is? I don't want to experience this twice, and I don't think the world would like that too.

So my statement should be clear: I'd like to continue using your provider and I would be pleased, If the project will receive furthermore support from you and the community! :+1:

[caleblloyd]

I've taken a look at Oracle's new driver and I don't think it's any good at all. Their pre-release has bugs that make it unusable, JSON support is poor, and they don't give a timeline for fixes. I think that it's pretty clear that Oracle is not very committed to their .NET Core Entity Framework driver.

I agree with what others have said in this discussion: the underlying ADO.NET driver needs to be switched to https://github.com/bgrainger/MySqlConnector since it is a real MIT-Licensed library, focuses on fast async implementation, and is developed completely outside of Oracle. Once this change is complete in a backwards-compatible manner, Pomelo.Data.MySQL can be discontinued and the necessary JSON logic can be maintained in this repository.

I've started a PR at #44 to switch the ADO.NET driver to MySqlConnector. I think that with the community focusing on this repository and MySqlConnector, we can make a de-facto standard for running EntityFrameworkCore with MySQL!

[yukozh]

@caleblloyd thanks

[Knaackee]

Keep going! I use this to connect to e.g. google cloud sql. The official driver does not support SSL yet.

[yukozh]

Close this issue as we will keep maintaining and provide developers a real mit licensed, async supported mysql provider for ef core.