Specifically in:
Okay for 3.0, but we should revisit what public abstraction is needed here.
@ajcvickers A compromise here may mean that the Couchbase provider will have to do the same thing for 3.0 support.
@mgroves what are your current plans for 3.0?
I don't know enough to provide a good answer. The only real plan I have right now for EFCore 3.0 support is "get something working". What kind of effort would this compromise include for Couchbase support?
@divega @mgroves I'm not too concerned. To explain in a bit more detail, EF Core has "internal" types that are actually public as far as the language is concerned--so called "pubternal" types. These allow developers to unblock themselves when they need something that cannot be done using only the public API surface.
In general, as an app developer, you do this at your own risk, understanding that the pubternal types may be changed in breaking ways between releases. However, we try to ensure that providers (and other extensions) don't need depend on these pubternal types because that would mean, for example, an EF Core update from 3.0 to 3.1 could break providers, which is something it can be hard for people to workaround.
In this case, the Cosmos provider is using InternalEntityEntry which is a pubternal type. Couchbase may need to do something similar. However, as long as we know what APIs Couchbase and Cosmos are using we can be careful not to break these APIs. So the ask from our side is that if you do end up using pubternal APIs, then send us a quick message to let us know.
@ajcvickers That makes sense to me. Right now, I wouldn't call our EF Core 3 efforts anything close to official. Right now it's just a copy of the (old, probably) Cosmos provider, which myself and a couple of non-Couchbase people have started to make small progress on. So that is to say, if Cosmos is doing it, my Couchbase fork is also doing it, but not necessarily because I've intentionally done it :)
Most helpful comment
@divega @mgroves I'm not too concerned. To explain in a bit more detail, EF Core has "internal" types that are actually public as far as the language is concerned--so called "pubternal" types. These allow developers to unblock themselves when they need something that cannot be done using only the public API surface.
In general, as an app developer, you do this at your own risk, understanding that the pubternal types may be changed in breaking ways between releases. However, we try to ensure that providers (and other extensions) don't need depend on these pubternal types because that would mean, for example, an EF Core update from 3.0 to 3.1 could break providers, which is something it can be hard for people to workaround.
In this case, the Cosmos provider is using
InternalEntityEntrywhich is a pubternal type. Couchbase may need to do something similar. However, as long as we know what APIs Couchbase and Cosmos are using we can be careful not to break these APIs. So the ask from our side is that if you do end up using pubternal APIs, then send us a quick message to let us know.