Pomelo.EntityFrameworkCore.MySql VS MySqlConnector

EntityFramework uses providers to translate Linq queries into real queries and connect to the datasource and convert the data into .net readable format. The MySQL provider for .NET is the official one but I think it has fallen on hard times and is not developed as much as before. You should probably look at Pomelo, which is a community library for .net core: https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql

For MySQL and friends you'll need the Pomelo data provider from https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql . Turns out there's an example of using the MySQL provider about halfway down that shows how to, but it is missing the '-o Model' parameter that you'd use to get your database model into a folder called Model.

This approach has become my preferred way of generating IDs for database rows. It is relatively space efficient and doesn't require a round trip to the database to generate an ID like auto increment does.

While working on a C# implementation for MySQL and we found that when the DB uses Little Endian Binary that the GUID must be reversed to store in order:

https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCo...

MySqlConnector (the most popular .NET library for MySQL, and the one that I authored) has supported protocol compression for many years: https://github.com/mysql-net/MySqlConnector/issues/31.

> I kept technical notes about the protocol, to serve as a future reference for myself and for other developers.

As someone who's written a MySQL client (in C#: https://github.com/mysql-net/MySqlConnector), I'd be very interested to see your notes. Are they available anywhere, or were they the confidential IP of your client?

> Unsurprisingly, bugs were uncovered every time a new client was added.

I've faced the same thing, from a client perspective. Every time a new server is tested (MySQL, MariaDB, Amazon Aurora, Azure Database for MySQL, etc.), I find slightly different interpretations of the protocol and have to accommodate them.

I have had the pleasure of contributing to a couple different networked drivers with very talented maintainers that I like to use as references.

One supports a wide array of Framework versions and has both Sync and Async I/O, as it must to implement the ADO.NET database driver interfaces. Reading the internals really highlight the way that .NET has evolved over the years and what must be done in each target version to maximize performance:

https://github.com/mysql-net/MySqlConnector

The other supports .NET 6 only with Async I/O only. This support policy seems to be the way that "modern" .NET development is headed, as .NET 6 will be the floor for LTS .NET (formerly .NET Core) releases in a few months. Async APIs only greatly simplify development, and make it simpler to remain performant when targeting WASM.

https://github.com/Cysharp/AlterNats

As a library maintainer, one thing I often wonder about is how to indicate .NET version support. One option would be for the major version of the library to track the major version of .NET, so if I were to publish a new library today then start with .NET 6 support and start with version number 6.0.0 instead of 1.0.0. This would limit the library to only making breaking changes when the .NET version changes though.

Use the MySqlConnector to load the data into a temp table using the bulk copy API. Both of my libraries implement the IDataReader (DbDataReader) interface, so they can be directly used with the bulk copy APIs. Then insert into the final table from the temp table filtering out rows that are already in the final table.

I'm the author of what you might call the "new" MySQL ADO.NET library: https://github.com/mysql-net/MySqlConnector

I agree with your impression that developers of the other library don't seem to be "plugged in to" the .NET ecosystem. As an independent developer (not affiliated with Oracle or Microsoft), I've been able to influence GitHub PRs that shape the ADO.NET API for .NET 6.0, just by showing up and contributing; I haven't seen anyone from the Oracle MySQL team participating. Meanwhile, they violate basic principles of the .NET Framework Design Guidelines that have been around for over a decade (https://docs.microsoft.com/en-us/dotnet/standard/design-guid...), which makes their library feel alien to a .NET programmer (regardless of the quality issues it might have).

e.g. this community effort of a MySQL ADO.NET provider is miles ahead of Oracle's driver.