Move DatabaseLoader from the Experimental package

[eerhardt]

We want to mark the DatabaseLoader as a "stable API" when we ship 1.4. However, it is currently in the Experimental package, which will never be marked as stable.

We should move the DatabaseLoader to a stable package.

If I get a vote, my vote would be to add it to the core Microsoft.ML package, next to TextLoader. DatabaseLoader adds no extra dependencies, so I think it is completely fine to add it to the Microsoft.ML package.

[eerhardt]

fyi - @codemzs @ebarsoumMS

[tannergooding]

If we can confirm where it should go, I'm happy to move it there.

[eerhardt]

If I was to do it, I would move it next to the TextLoader. I don't feel adding a new package for this is valuable since it doesn't add any new dependencies.

@CESARDELATORRE @codemzs @yaeldekel - thoughts? We need this in order to ship a stable 1.4 package with the DatabaseLoader in it.

[CESARDELATORRE]

I agree. It should be near the TextLoader type if ti is not adding any new dependencies.
It’d be a very small package if adding a new one.

[tannergooding]

Any other input I should wait for, or am I good to move the types and put up the PR?

[codemzs]

What if tomorrow DB loader adds new dependencies?

[tannergooding]

Move the type into a new assembly and add a type forward at that point?

[eerhardt]

What if tomorrow DB loader adds new dependencies?

If that is necessary, we could add those new dependencies in a separate NuGet package as extension methods to the lower-level DatabaseLoader.

A key design to the DatabaseLoader is that it works on any ADO.NET provider, it isn't specific to SQL Server, Oracle, etc. So the low-level/base classes should have no dependencies outside of the base System.Data.Common. If we need new dependencies, they will have to be separate from the base DatabaseLoader anyway.

[codemzs]

Ok, sounds good. Let’s move it out of Experimental nuget. Thanks @eerhardt and @tannergooding