SqlConnection.GetSchema is missing override in SqlClient

[saurabh500]

The SqlConnection.GetSchema() API implementation is missing from SqlConnection

[karelz]

@saurabh500 I assume you wanted to address it in 2.0, right?

[saurabh500]

@FransBouma What is your thought on the priority of the SqlConnection.GetSchema() API and its overloads? I remember from one of the past discussions in https://github.com/dotnet/corefx/issues/5024#issuecomment-173861443 that this was important for LLBLGEN.

Quoting a comment

I use the information to build up meta-data models so my entity modeling system (LLBLGen Pro, http://www.llblgen.com) can use these to reverse engineer entity models from them or allow users to map entity models onto them. In general, none of the ADO.NET providers out there provide enough schemas for all metadata I need, sometimes there are only schemas returned for the table definitions, others provide a more broad spectrum of schemas. I use them first to build my meta-data models and for the spots where there's no schema table provided, I use sql queries to read the meta-data directly from the database. This is often a complex affair so the schema tables are very handy (as meta-data in some databases is hidden away / stored in very odd ways like in postgres for example).

[saurabh500]

@karelz I feel that this is important for Schema driven applications and I will keep it for 2.0

[karelz]

Sounds good.
If the experts agree it is important, we should not leave it out, unless it is XXXL costly (and we are running out of time). We don't want to ship API surface which will work only for 10% of customers. I would prefer it to be in the 80%-90% range (we can shoot for perfect in next release). Thanks!

cc @NickCraver @cincuranet @FransBouma

[FransBouma]

For me personally, they're less important as I only use them on desktop, but I can imagine there's code out there which is using these schema tables, even if they're sometimes incomplete for the complete picture (in general, in my experience, you always have to do some custom queries to get all the meta data from the schema in the catalog, but existing schemas can help a great deal without a lot of effort).

For porting efforts to port code over from full to core it might be crucial that these schema tables are there, but I can't say how many people are affected by this: even if the group of users who directly uses this API is pretty small, the amount of people affected by that work indirectly might be massive.

So I think if porting code over from full by copy/pasting the queries from the full SqlClient code is doable, I'd do it to make sure people porting code over don't run into a nasty surprise. (Assuming that the code in the .net full implementation of sqlclient is relatively easy to port to core)

[saurabh500]

Fixed with dotnet/corefx#20004