[Discussion] New provider design

[ErikEJ]

Some thoughts, let me know what you think!

• Use package references to 3.1.3 EFCore.Relational

• Implement as a .NET Standard 2.0 library

• Consider using System.Data.Odbc as ADO.NET provider !?

• Add mostly shallow interface implementations throwing NotImplemented Exception

[ErikEJ]

@bricelam @roji

[smitpatel]

Any reason for not making it ns2.0 lib vs netcoreap3.1 lib?

[ErikEJ]

@smitpatel No, I guess I should just do that! Thanks...

[roji]

Use package references to 3.1.3 EFCore.Relational

👍

Implement as a .NET Standard 2.0 library

👍

Consider using System.Data.Odbc as ADO.NET provider !?

I'm not sure what the value of that would be... After all, as discussed before this wouldn't make the provider actually compatible with any database (specific SQL constructs and other behaviours need to be implemented per database). I'm not sure the typical user of this provider skeleton is there because they want to build an ODBC provider, and the ODBC integration may be more confusing than anything else to someone wanting to build a totally new provider...

Add mostly shallow interface implementations throwing NotImplemented Exception

Yeah, that's how I'd imagine it - but leave only the absolutely necessary things to throw. In other words, Relational already provides a lot of default behavior which makes sense - we shouldn't force users to look at things which may be reasonably expected to just work. Of course we can discuss on a case-by-case basis.

[ErikEJ]

I'm not sure what the value of that would be.

I was under the impression that I would have to pick some ADO.NET provider in order to build anything - but of course I could easily be wrong ? If so, any suggestions for another ADO.NET provider to choose?

[roji]

I don't think you'd have to pick a specific ADO.NET provider in order for the provider to build - of course nothing will run without an ADO.NET provider, but then again the same is more or less true if you use ODBC without any customizations...

One (somewhat unrelated) idea is to use #error to fail compilation for places in the provider which must be done by the user (instead of NotImplementedException). For example, every relational provider needs to have its version of RelationalConnection, which is responsible for instantiating the provider's version of DbConnection (CreateDbConnection). In the skeleton provider, I'd override that abstract method, but put an #error in the implementation with an explanation that this is the place where they need to return a valid DbConnection etc.

[ErikEJ]

Yes, RelationalConnection was the exact reason I would want a concrete ADO.NET provider.
I will just also add NotImplemented for now, and sprinkle with some comments, until the provider at least builds. I also plan to add some readme guidance

Not sure what you mean by #error, though.

[roji]

C# has a nice feature where you can have:

#error This fails compilation with a nice error message
#warning This creates a warning in compilation

NotImplemented is a runtime-only error, and the user may have a harder time to understand exactly where to go and what to do... whereas #error/#warning give a clear compilation error where we can direct the users to go and plug in their ADO.NET provider (or anything other message).

[DavidTuke]

Hello All;

Any thing to look at here?

I have an upcoming project with Microsoft Dataverse; but am averse to using their awful "client"; which is like EF but different enought to be both annoying and just plain dumb.

I thought I would experiment with a efcore compatible provider for MS Dataverse; hide all the akward "client"string based coding style. Thus I wound up here after some dead ends (AJ Vickers How To should be at least flagged or removed please, all wel out of date, nogin or no...)

Anyway - how are things here going, any movement?

Keen to help if possible move things along I know both EF; EFCore & CDS/Dataverse.
Driver for me is an app I can port to CDS/Datavers and SQL Server by changing the EF Driver.
Dataverse is moving quicky as "low code"
alternative - but my (financial) app still requires sophisticated logic (ie C#); Dataverse client is like working with SOAP in code (ie strings everywhere)
Cheers

[ErikEJ]

Is DataVerse based on ADO.NET ? - if not, you are to some extent out of luck here.

[ErikEJ]

@DavidTuke I have a PR with support for the Dataverse SQL endpoint in (for reverse engineering and query)