Migrating provider to 3.0

[cincuranet]

Is there any "document" describing all the changes when migrating provider from 2.2 to 3.0/3.1? I found #15405, but that's more or less only list of providers-beware tag for 3.0. What I'm mostly interested it changes in query processing and model handling, because that's where most of compilation errors happens for me at the moment.

[ajcvickers]

@cincuranet Unfortunately no. The team will try to provide help wherever we can. Also @roji and @lauxjpn have done this for Npgsql and MySQL and so may be able to help.

[roji]

@cincuranet anything in particular you're blocking on? I'd be happy to provide any assistance etc.

[cincuranet]

At the moment I'm trying to make it build, at least. Fair to say I blindly updated the references to 3.1 in the name of to see what's what. :D I'm looking into EFCore sources and commits in Npgsql to speed things up. If you can give me some pointers, it would be appreciated (I'll keep working on that myself, so whatever comes first is a win 8-)).

• Where's RelationalModelBuilderAnnotations, RelationalPropertyAnnotations and similar types?
• Replacements for RelationalCompositeMemberTranslator, RelationalCompositeMethodCallTranslator, DefaultQuerySqlGenerator, etc.?
• RelationalConventionSetBuilder and related?

[ajcvickers]

@cincuranet On the first point, see https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#provider-specific-metadata-api-changes. The API surface was flattened out. /cc @AndriySvyryd

[lauxjpn]

@cincuranet As a general guideline, you can dive into our PomeloFoundation/Pomelo.EntityFrameworkCore.MySql#822 PR, which contains most of the conversion work done for the MySQL provider for the upgrade from 2.2.6 to 3.0.0, and consists of 79 individual commits with each of them containing a short description of what has been done.
It will also provide a general overview of what files were removed and added.

To migrate something specific, here is what I usually did (when only using GitHub as a tool):

• Open @roji's https://github.com/npgsql/efcore.pg repository and change the branch to hotfix/2.2.6 and click on Find file.
• Open another tab to the repository, but stay on the dev branch (the default).
• Use the 2.2.6 tab to look for the corresponding file you want to migrate. E.g. if I want to migrate MySqlQuerySqlGenerator, I would search for NpgsqlQuerySqlGenerator on the 2.2.6 tab to find the old file. I would then do the same on the dev tab and then either do an actual diff, or would just use the dev tab as a reference.
• In case I wouldn't find the corresponding file on the dev tab, I would use the general GitHub search function Search or jump to... on the dev tab (this search will only look through the default branch) to search (using in this repository) for something unambiguous from the 2.2.6 file (e.g. a typeof() that would only make sense there) to find the corresponding file or implementation for 3.0.0.
• Doing this locally with a strong search tool might be more powerful.

Generally speaking, you can assume that most things you used in 2.2.6 will have an equivalent in 3.0.0. So having a local clone of the EF Core repo and the Npgsql repo, both at the same time as the 2.2.6 and 3.0.0 version, will be handy.

Make sure to reference the local EF Core repo's assemblies for development instead of the Nuget packages, so you can directly navigate through the actual EF Core source code (especially when using Resharper) from inside your own VS solution.

[cincuranet]

@lauxjpn That's in general what I do. But sometimes the code does not explain the reasoning behind and it's difficult to make a right decision if you don't know all the places that fit together especially as the code does not compile yet (at the moment trying to understand ApplyTypeMapping).

[lauxjpn]

@cincuranet I had similar problems when starting with the migration. I just mirrored what Npgsql or Sqlite did and left bookmarks behind when I was unsure about decisions I made on the spot, to which I came back to after I got everything to compile and thus the tests to run again.