Database constructor - bug when ProviderFactory is not set

[huanacaraz]

When you use constructor with connection parameter, any query will fail unless you provide the DbProviderFactory. The result is System.NullReferenceException in
function: OpenSharedConnectionImp(...)
line: _sharedConnection = _factory.CreateConnection();

how to reproduce:

string dbconnstr = @"some valid connection string";
var conn = new SqlConnection(dbconnstr);
var db = new Database(conn);//, DatabaseType.SqlServer2012); //, SqlClientFactory.Instance);
var o = db.Query<Poco>().FirstOrDefault(a => a.Property == value);

[Radar5000]

I am having the same problem in .Net Core RC2. I would like to point out that if you open the connection (conn.Open()) before you create the Database object it will proceed with the query without having to provide the DbFactory. Either way I believe this is a bug that needs to be resolved.

How is NPoco handling multiple connections? Is it still using a shared connection pool?

[schotime]

I don't think this is a bug. Its functioning as expected. If you are providing a DbConnection object, you are required to open and close the connection itself. We will not open or close it for you.

Multiple connections is multiple Database objects. The Database object is cheap to create and is really a wrapper around a connection.

[schotime]

In fact the bug might be that you can pass the DbProviderFactory in to the constructor with a DbConnection

[huanacaraz]

Then if it is meant this way, I suggest it should recognize this 'different' initialization mode, automatically open and close connection if passed as not open to constructor. And Open/CloseSharedConn() should do nothing in this mode (or even throw exception).
The 'KeepConnectionAlive' is also invalid in this mode probably, as it should be set automatically to true? (because once you close the connection you can not create new, because of missing factory)

[schotime]

This is exactly what it does do. I have added an exception if you don't open it yourself now but what you have suggested is how it currently works.

[Radar5000]

Would it be possible to add other constructors to make it more like the previous versions? I'm not an expert in this but here are two examples: 1)remove the DbProviderFactory 2)pass just the connection string and DbProviderFactory.

Are there any plans on updating the documentation for this? I see how a lot of people just starting can be confused by the limited options in the constructor choices that are allowed for .Net Core. I believe that we will see a rise in the number of people trying it out but be overwhelmed because they were used to the old ways. The current example listed on the README.md (similar example in Wiki) is invalid for .Net Core:

public class User 
{
    public int UserId { get;set; }
    public string Email { get;set; }
}

IDatabase db = new Database("connStringName");
List<User> users = db.Fetch<User>("select userId, email from users");

Compare it to this which is valid for .Net Core:

//SQL Example
public class User 
{
    public int UserId { get;set; }
    public string Email { get;set; }
}

SqlConnection conn = new SqlConnection("connString");
IDatabase db = new Database(conn, DatabaseType.SqlServer2012, SqlClientFactory.Instance);
List<User> users = db.Fetch<User>("select userId, email from users");

At the end of the day if we can make it a little more intuitive like it has been for the previous .Net frameworks it can really go a long way for someone who is trying to figure out the other aspects of .Net Core.

[schotime]

This has landed in Nuget 3.4.0.
DbFactoryProvider has been removed from the connection constructor.

Core can do this as well as pass the connection in.

IDatabase db = new Database("connString", DatabaseType.SqlServer2012, SqlClientFactory.Instance);
List<User> users = db.Fetch<User>("select userId, email from users");